A business requirement defines what the business believes to be important for the success of the project. The business typically comprises management or stakeholders who are funding the project. The requirements can be kept and tracked at a high level. An application architect will have to translate requirements into specifications and design.
User requirements are the tasks the users must be able to accomplish to meet the objectives of their jobs. Ex: A customer service representative must be able to place an order for a customer. These are all high-level user requirements that usually lack use-case definition and specifications. Typically a business analyst will then detail a number of steps that are involved in the user requirement process. In addition, an architect should define the specifications for the given requirement.
Developers need to know what constitutes an order, what fields are required, what rules will be processed, and so on.
Functional requirements or functional specifications are the features the developers must build to satisfy the other requirements. These requirements are typically defined in great detail to help developers understand exactly what it is they need to develop. The functional requirements are typically written by a technical lead or architect. A functional requirement, for example, might be to create an ASP.NET Web page for managing a customer’s profile. The functional requirement should include the name of the page, the controls used on the page, the input validation rules, the security rules for the page, the classes that should be called to support the page’s functionality, and so on. As you can see, functional requirements can be very detailed. It is often better to do functional design rather than to write functional requirements.
Quality-of-service (QOS) requirements define the contractual, or non-functional, requirements for the system. QOS requirements do not typically represent specific user problems. Rather, they define the requirements around things such as performance, scalability, and standards. Ex: All customer-facing page requests in the site should return to the user within five seconds over a standard high-speed Internet connection.
Requirements and use cases have two different goals. Requirements define what needs to be created for the system to be successful. They are useful for defining scope and determining whether you have met objectives. Requirements are often traced all the way through the implementation process. Project managers and testers create requirements traceability matrices that define how a requirement is realized through the system.
Use cases, on the other hand, are meant to define a set of steps to reach a common user goal. Use cases are more about the process by which a user reaches a requirement. They help architects, developers, and testers understand how people work and how the system should accommodate their activities. They are not, if written correctly, requirements
Evaluating the Requirements for the Application
- Requirement perspectives Are all requirement perspectives considered? Do you have definitions for the business, user, and QOS requirements? Can you derive the functional requirements and design from this set of requirements?
- Unambiguous Does each requirement define a specific, actionable scope item? Can each requirement be acted upon? Make sure that there are no soft requirements.
- Complete Are the requirements complete? You need to identify missing elements in the requirements. You should also indicate where further clarification of one or more requirements is warranted.
- Necessary Are all the requirements actually necessary to satisfy the goals of the application? Sometimes business analysts, developers, and architects can add things into the system that are not really required.
- Feasible Are the requirements, as they are documented, really feasible? Review the requirements against known constraints such as budget, timeline, and technology.
Defining the application’s requirements, making your technology recommendation, and creating a high-level design are the necessary risk-aversion steps to begin your project. You will use this information to define a prototype, refine your design, and begin creating detailed specifications and an application architecture.
- Application requirements should be defined from multiple perspectives. This includes the business or executive sponsorship, the users, the developers (functional), and the quality of service (non-functional).
- Your functional requirements or functional specifications are better off defined through application modelling tools. You should not have to document this once on paper and again in the models.
- A good requirement should be unambiguous, measurable, and actionable. It should neither read like a goal nor be left open to interpretation.
- Verify that all your requirements are necessary to the success of the system. Those that are not should be set aside.
- It is important that developers and architects make recommendations that match the real requirements. They should not recommend technologies only because they are cool or available. Rather, they should perform careful analysis and make proper recommendations.
- Always review your recommendations against existing solutions. There might be an offtheshelf product or an internal company asset that you can use.
- Start the process of validating your recommendations by creating a high-level application design. This should include your recommendations in terms of technologies, how these technologies integrate to form a solution, and any configuration parameters and constraints of these items.