Draft Version 0.5, December, 2003
Requirements engineering takes a fair amount of experience to become proficient at it. Even then, much of the process involves work with business-specific processes and jargon. Thus, you need a good understanding of the business to do a good job gathering and analyzing requirements for a particular business.
Recognizing that, it should be obvious that requirements engineering is a collaborative effort. Software developers often find themselves invited to meetings where requirements for a project are to be discussed. Their role is expected to be technical advisor, stating 'that can be done' or 'that would take forever', etc., and the document resulting from that meeting is a bulleted list of features - maybe prioritized and probably with due dates.
For small informal projects that will take one or two days, a simple bulleted list of features may be fine. Other projects should ramp up the formality and size of the requirements with the formality and size of the project. The key reasons are:
Three classes of requirements are the products of requirements analysis and design:
Likewise, the requirements document names are:
Document naming conventions are loose - other documents you may have heard about and their roles in the requirements process:
A good approach to requirements documentation is to start with templates.
Projects grow out of some need, say in a business environment. Some opportunity is defined - a product or a way to make the business run more efficiently - and a solution is envisioned. In its simplest form the envisioned solution is the objective of the project, the vision of the solution.
At this point the business objective is known, and a few definitions about the project should be written down in a vision and scope document:
The business objective helps define limits for project requirements - the features and functions that will be present, i.e. the scope of the requirements. Any requirement that does not apply to the business objectives should be removed. Add descriptions of project scope to the vision and scope document:
Software requirements specifications (SRS) contain both funtional and nonfunctional requirements of the system.
Functional requirements are documented in a functional specification. The functional specification describes the system by specifying both input and output conditions. The system is described in detail, including the program's purpose, constraints and flexibility, and features by project phase. Functional specifications should include:
These are characteristics the system must exhibit, usually considered quality attributes because they do not relate to any specific function of the system
Not directly part of a requirement, the data dictionary defines business specific terms and technical terms. Particularly, terms that have different common and technical meanings. This should be separate from the SRS, and not duplicated in other documents to prevent the situation where terms are defined differently in the documents.
Wiegers, Karl E., 1999, Software Requirements: Microsoft Press, 350 pages. ISBN: 0-7356-0631-5
Kruchten, Philippe, 1999, The Rational Unified Process: An Introduction: Addison-Wesley, 255 pages. ISBN: 0-201-60459-0Top of page