Requirements are used to define these constraints and articulate beyond any misinterpretation the software system to be build.
The term “requirement” is used very broadly in software systems. It includes:
The Functional requirements state what the system should do and what the system should not do. Meaning how the system will handle input and what output to produce.
The non-Functional requirements describe attributes of the system as a whole. To give an example, a non-Functional requirement may be the response time of the system to user requests.
Domain requirements are derived from the application domain. This means that the software system might comply with some international standards.
I think that it is important to use a categorizing schema in order to be sure that all requirements are covered and to reduce the risk of not considering some important aspects of the system.
FURPS+ is used in Unified Process to categorize requirements. FURPS stands for Functional,Usability, Reliability, Performance and Supportability. The + stands for Implementation, Interface, Operations, Packaging and Legal.
It is very important to validate requirements after defining them. Correcting requirements during a requirements review has a small cost for the project. If errors to the requirements are found in later stages of software developement the cost to correct them is much bigger.
Stakeholders of the system may have different needs from the system and sometimes these needs may be conflicting. Thus, it is important to perform validity and consistency checks to the requirements. The customer and the software development team should review the requirements to ensure that the requirements correctly describe the system to be build. All the requirements of the system should be verifiable and comprehensive. It must be clearly stated who enforced a requirement in order to be able to trace back to the originator in case of a requirement change. For each requirement is good practise to state the adaptability of the requirement, meaning what the effect on the system will be if the particular requirement is changed.
After the requirements are reviewed and the proper use cases are written along with all the documentation to describe the system a requirements management system must be activated in order to:
It is very important to have a conflict resolution procedure to detect and reolve conflicts. Stakeholders must have active involvement in change requirements interaction. Monitoring change and active stakeholder involvement greatly reduces system errors and increases stakeholder satisfaction and system effectiveness.
As a coclusion it is important to walkthrough the customer through the system using use cases and scenarios discussing all requirements. It is also important to insist that domain experts be present to correclty identify the requirements of the system.
References
Larman Greg(2002). Applying UML and Patterns:an introduction to object oriented analysis and design and the Unified Process. Prentice Hall 2nd ed.
Robinson,W.N, Pawlowski, S.D, and Wolkov, V(2003). Requirements interaction management. ACM comput. Surv. 35,2 pp. 132-190. DOI=http://doi.acm.org/10.1145/857076.857079
Sommerville,I (2006). Software Engineering. Addison Weasly/ Pearson 8th edition.
Wiegers, Karl E.(2003). Software Requirements, Second Edition. Microsoft Press
]]>