Requirement vs Specification
- Requirement are collection of statements about phenomena in the Environment that we want the System to help make true.
- Specification is a collection of statements that describe a System's external behavior, as observable through the Interface.
- A requirement statement is not a specification statement if it is not expressed in terms of interface.
- A SRS documents the requirement and specifications.
- What is better than how.
- A good user manual needs description of underlying and fundamental concepts of the software, a graduate set of examples that shows solution to problems, a systematic summary of all the commands.
Requirements Iceberg
- Traditional waterfall does not work. Main problem is due to the sanctity and unchangeability of requirements. It also implies that all steps are equally systematic.
- The hardest part of design is deciding what to design.
- The essence of building software is devising the conceptual construct itself.
- Spiral model develops both requirements and implementations incrementally.
- V model tries to indicate different volumes of information flow and put test planning and testing everywhere.
- There exists functional and non-functional requirements.
- RE is identifying customer needs, creating documents that describe the external behavior, ensuring consistency and evolution of these needs.
- 3 kinds of system requirements are normal (users mention these), exciting (invented by developers), tacit (understood by user, not by developers.
- 75%-85% of SW error can be tracked back to requirements and design phases.
- Errors happen either they are not understood or expressed correctly, or not expressed at all.
- Fred Brooks observed that a general purpose system is harder to design than a special purpose product.
- Requirements will change, and will be misunderstood.
- Requirement is the hardest part of the system development since we don't understand everything or we cannot express everything that we know.
- The more you study the problem, the lower the costs, the fewer the surprises and more accurate the cost estimates are.
- Requirements are not easy to obtain, for clients do not know what they want.
- We cannot start coding before we know what to code.
- Requirements are invented, not captured or elicited.
- Policy may not make sense over time.
- 3 kinds of creativities requirement engineers need are: exploratory creativity, combinatorial creativity, transformational creativity.
- Formal methods formalize misunderstandings and may make them harder to detect.
- Kevin Ryan's RE Process
- Identify requirements
- Document requirements
- Validate requirements
- Verify
- Rank requirements by priority
- Select and plan requirements
- Must rank requirement:
- absolutely essential
- essential
- important
- nice
- fluff
- A particular way to use a system is called a use case.
- A scenario is a particular sequence of interaction steps between a user and the system.