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
]]>Although in my opinion, many of the proposed areas are covered from the SWEBOK some areas are left uncovered. The role of an IT Architect is to understand the broader needs of the organization, to visualize the technological structure of the organization.
The IT Architect must know in relative depth the technologies she proposes. The IT Architect must also have training in management and in project management. These two areas are usually out of the job description of a Software Engineer.
The IT Architect will be responsible to communicate her architecture to both technical and non-technical stakeholders. I believe that an ArcBOK can complement the SWEBOK. It is easier that a Software Engineer becomes an Architect than a manager or a project manager becomes an IT Architect; because they have no technological training in depth .
We will see the results in the future.
References
IEEE Computer Society(2008). Guide to the Software Engineering Body of Knowledge . Available at: http://www.swebok.org/
Miha Kralj(2008). The Need for an Architectural Body of Knowledge. Available at: http://msdn.microsoft.com/en-us/arcjournal/cc505967.aspx
]]>