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.