Obtaining, writing and sharing software requirements is one of the most important steps in any software project, a project can fail at any other stage, too. Requirements are the features that your application must provide to your users or customers. Throughout development, you use the requirements to guide development and ensure that you’re heading in the right direction. At the end of the project, you use the requirements to verify that the finished application actually does what it’s supposed to do. Software requirements are part of software engineering.
The document that has the software requirements in it is sometimes the Software Requirement Specification, or SRS.
For large mission-critical projects your requirements must be detailed and unambiguous. Good requirements are clear, concise, and easy to understand.There is a temptation to hurry through the requirements and get to coding, but this can cause delays later on.
A project’s requirements must be consistent with each other. That means not only that they cannot contradict each other, but that they also don’t provide so many constraints that the problem is unsolvable.
Requirements may need to be prioritized. For small projects, you probably don’t need to do this because you will have a list of requirements that all must be met. Larger projects may have a list of must-haves and another list of nice-to-haves.
MOSCOW Method
The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. Must, Should, Could and Won’t.
Requirements labeled as Must have are critical to the current delivery timeline in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure.
Requirements labeled as Should have are important but not necessary for delivery in the current delivery timeline. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timeline.
Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.
Requirements labeled as Won’t have have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won’t have requirements are not planned into the schedule for the next delivery timeline.
Requirements must be verifiable. If you can’t verify a requirement, how do you know whether you’ve met it? To do this you could use numbers and times and words like “at least” or “no more than”. In other words the requirement must be measurable.
Categories/Types/Kinds
There are several kinds of requirements that are aimed at different audiences or that focus on different aspects of the application. For example, business requirements focus on a project’s high‐level objectives and functional requirements give the developers more detailed lists of goals to accomplish. You can use the categories as a checklist to make sure you’ve created requirements for the most important parts of the project. The following list has four ways to categorize requirements.
- Audience‐Oriented Requirements
- FURPS
- FURPS+
- Common Requirements
At this point you know what makes a good requirement (clear, unambiguous, consistent, prioritized, and verifiable). You also know how to categorize requirements using audience‐oriented, FURPS, orFURPS+ methods. But how do you actually pry the requirements out of the customers? How do you actually gather requirements from users?
Gathering Requirements
Here is a list of some techniques you can use to gather requirements. This is also called requirements elicitation.
- Listen (Interview) Customers
- Use the Five Ws (and One H)
- Study/Watch Users
Refining Requirements
After you’ve talked to the customers and users, and watched the users at work, you should have a good understanding about the users’ current operations and needs. Next, you need to use what you’ve learned to develop ideas for solving the user’s problems. You need to distill the goals (what the customers need to do) into approaches (how the application will do it).
Moving from goals to requirements often forces you to make some design decisions. For example, you may need to specify form layouts (at least roughly) and the way work flows through the system. You might think of those as design tasks, but they’re really part of requirements gathering.
Recording Requirements
At this point you will have a list of requirements in either point form of full sentence form.
Validation and Verification
After you record the requirements (with whatever methods you prefer), you still need to validate them and later verify them. Requirement validation is the process of making sure that the requirements include the right things and not the wrong things and that they include all of the necessary things. Requirement verification happens after the project is coded. Requirement verification is the process of checking that the finished application actually satisfies the requirements.
Changing Requirements
Requirements may change over time. As you learn new information from customers or users, you may need to change or add to the requirements you have. Customers (and others) can submit change requests. A decision maker or group of decision makers will decide whether or not the change request will pass on to development, or be deferred to a later time, such as Phase II, or be rejected.
You might encounter major changes to your requirements. Suppose for example you are developing a website for internal company use that allows your clients to log in. Perhaps you determine that the software could be licensed to other companies in your industry and after speaking with them you realize that they have many additional requirements you hadn’t considered. If the market is promising, you may decide to change your requirements by adding several new requirements.
Your requirements should be SMART. Specific, Measurable, Attainable, Reasonable and Traceable. These are based on Peter Drucker’s SMART Goals (or objectives).