As a business leader, you may be considering developing a web application for your team, your company or customer use. Congrats! Let’s get your project off to a good start with a clear and concise Software Requirements process.
Throughout this series of Software Development Guide for Business Leaders, we will help you to understand the elements of success in a software development project.
As the leader, (aka project sponsor), your contribution will be paramount in defining the software expectations and your input will be required throughout the project lifecycle to ensure that everything stays on track and there are no surprises at the end of the project.
Finding the Aces – What is a Software Requirement?
Project Managers break software requirements into functional and non-functional components.
Functional requirements are simple documents that outline the inputs, the behavior of the software and the outputs. An example could include a login screen. You will have very specific inputs (typically username and password fields) and actions for different scenarios (login success, login failed, reset password, etc.)
The non-functional requirements include details such as performance requirements, security, or reliability. A good example would include a requirement for role-based security. This would change the features of the system depending on which user level an individual has logged in (administrator, contributor, general users, etc.)
Seems simple, right? It’s critical that we get these software requirements right before we start developing. Product quality, delivery timelines, and budget are all dependent on the quality of requirements. So, what can we do stack the deck in our favour?
Shuffling Methodologies – How to Develop Software Requirements
There were two studies performed in the 1990’s that help us create better software today. A study by the ESPI in 1995 found that 40 – 60% of all defects discovered in a software project traced back to errors made during the requirements stage. An earlier study in 1994 by the Standish Group helped us understand that 13.1% of projects fail due to incomplete requirements and 8.8% of projects fail due to rapidity changing requirements (Girase, 2012). It may have been a long time ago… but this is largely still true today.
There are two mainstream project development methodologies in existence today. The older Waterfall method that has been around for decades and is still used today by many organizations and the more recent Agile Software Development Model which was established with the publication of the Agile Manifesto in February of 2001.
The Agile Software Development Model made many strides to resolve and improve project requirements gathering, however, our experience is that both Agile and Waterfall have their advantages and disadvantages and they are not for suitable for every situation. Traditional project management models, like Waterfall, still require documentation of a requirement before the coding and testing start while Agile is iterative and requirements are refined as they are built. Agile is flexible and allows for fast feedback and changes as the project unfolds.
Internal development teams should get more value from Agile as they have easy access to stakeholders who are very engaged in the software development process. Not every organization has the resources or bandwidth to be engaged through the entire process and most stakeholders will want to have the clear start and end dates (and project budget) before starting a development project.
We have used both Agile and Waterfall and while they both have their benefits, we feel that we’ve found a sweet spot in between the two methodologies. We approach our development through a hybrid model that utilizes the best from both models and focuses on a visual representation of requirements and the design of a functional prototype before any coding starts. To bring our clients software visions to life, our Milestone development process borrows the parts we like from Agile (The iterative nature of the project, and the fast feedback) and from more traditional development like waterfall (having a planned finish date). This ensures that our stakeholders are active participants in the design and functionality of the system on an ongoing basis. Through this process, we eliminate surprises at the end of the project.
The Final Cut – Defining and Documenting Your Software Requirements
So, you have developed spectacular objectives, your project is guaranteed to be a smashing success now, right? Well, no. Simply having clear and well-defined objectives isn’t necessarily enough. One of the biggest challenges in software development (or any other longer-term project) is that we have to capture and document the requirements specifically enough to limit how open they are to interpretation. Clear direction is essential, or your development team may come back to you to clarify, or worse, deliver what they “thought you wanted”. Have you ever had someone come back to you and ask you to clarify an objective or thought only to realize that they were on the wrong track?
So where do you capture requirements? Well if you’re like the vast majority, you’re probably capturing requirements in simple Excel files. However, there are much better solutions available that offer so much more. At CoreSolutions, we really focus on capturing and bringing your vision to life. Capturing requirements in a visual way is a key component to clarifying expectations and limiting revisions. We document the requirements through a software system called iRise. This allows us to develop an interactive prototype before a single line of code is written. The actual development coding is the most expensive part of any software development process so, by developing a working prototype of the system before we start development, we can more accurately estimate the development cost and stay on budget. While this is more upfront work, it does lead to greater project success and overall experience. Let’s face it, the requirements need to be captured at some point during the project so why not do that work upfront so you have a better grasp of scope, timeline, and budget. It just makes sense.
The figure above is an example of a screen that’s part of a prototype in iRise.
As we outlined throughout this article, with so much riding on effective requirements planning, it’s critically important to define and document goals and deliverables. Whichever project methodology you decide to use, capturing requirements means a lot of upfront work, but it’s worth it to ensure the success of your project. By using an effective project methodology, and really understanding and documenting your system requirements upfront, you will effectively be stacking the deck for your project’s success. If you want to stack the deck even more and need help planning out your next software project, reach out to us. We love helping prepare software visions and have been great at it for over 25 years.
CoreSolutions’ team of experts, including developers and project managers, build web and mobile applications using the Agile Methodology and tools. CoreSolutions will assist you in all phases of your project including:
· Brainstorming;
· Requirements Planning & Gathering;
· Prototype Design;
· Project Management.
Connect with CoreSolutions today to start your project by completing a Project Profile.
Works Cited
Girase, N. M. (2012, May). airccse.org. Retrieved 12 10, 2016, from http://airccse.org/journal/ijsea/papers/3312ijsea05.pdf
Mitre. (n.d.). Eliciting, Collecting, and Developing Requirements. Retrieved 12 12, 2016, from www.mitre.org: https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developing-requirements
Acceptable use policies outline when and how employees can use the business’ Internet access. Typically, these policies cover:
.png){kind=logo}
