Requirement engineering

• Requirements


  Something required, something wanted or needed
• Software requirements


  Complete specification of the desired external behavior of the software system to be built
• Software requirements may be abstract statements of services and/or constraints, or detailed mathematical functions
• Software requirements may be part of a bid or contract, or part of the technical document which describes a product
• IEEE definition of a software requirement


  A condition or capability that must be met or possessed by a system...to satisfy a contract, standard, specification, or other formally imposed document
• Sources of requirements


  • Stakeholders
  • Documents
  • Existing system
  • Domain/business area
• Requirements engineering process


  1. Requirements elicitation

  2. Requirements analysis

  3. Software requirement specification

  4. Requirements validation

  5. Requirements management

  
• Feasibility study


  Objective is to create reasons for developing the software that is acceptable to users, flexible to change and conformable to established standards
• Types of feasibility


  • Technical feasibility
  • Operational feasibility
  • Economic feasibility
• Requirements elicitation and analysis


  Identifying requirements with the help of customers and existing systems processes
• Problems of requirements elicitation and analysis include getting the right people involved, stakeholders not knowing what they want, stakeholders expressing requirements in their own terms, conflicting requirements, requirements changing during analysis, and organizational/political factors
• Techniques to elicit requirements

  • Questionnaires
  • Task analysis
  • Scenarios
  • Use cases
• Different types of requirements elicitation


  • Greenfield engineering
  • Re-engineering
  • Interface engineering
• Activities of requirements elicitation


  • Identify actors
  • Identify scenarios
  • Identify use cases
  • Identify relationships among use cases
  • Identify non-functional requirements
• Software requirement specification


  Document created by a software analyst after collecting requirements, written in technical language for the development team
• Requirements validation


  • Ensures requirements are correct, complete, consistent, realistic, and traceable
  • Manages requirements changes
• Prioritizing requirements


  High priority (core requirements), medium priority (optional requirements), low priority (fancy requirements)
• Kinds of software requirements


  • Functional requirements
  • Non-functional requirements
  • Domain requirements
  • Inverse requirements
  • Design and implementation constraints
• Functional requirements


  Statements describing what the system does, the functionality of the system, services the system should provide, reactions to inputs, and behavior in situations
• Functional requirements should be complete and consistent, and they often focus on the customer and developer's attention
• Functional requirements


  • The system shall solve a quadratic equation using a formula
  • The user shall be able to search the patient database
  • The system shall provide appropriate viewers for documents
  • Every order shall be allocated a unique identifier
• Incomplete and ambiguous functional requirements can lead to poor quality or faulty software
• Non-functional requirements


  Aspects not directly related to functional behavior, imposed by the client or environment, including constraints on timing, performance, reliability, security, maintainability, accuracy, development process, and standards
• Non-functional requirements are often more critical than individual functional requirements, and failure to meet them may make the whole system unusable
• Functional requirements


  Requirements that describe the specific behavior or functions of the system
• Non-functional requirements


  Requirements that describe aspects of the system that are not directly related to the functional behavior, such as performance, reliability, security, etc.
• Domain requirements


  Requirements that come from the application domain and reflect fundamental characteristics of that domain
• Inverse requirements


  Requirements that explain what the system shall not do
• Design and implementation constraints


  Requirements that are development guidelines within which the designer must work
• Non-functional requirements are often more critical than individual functional requirements
• Failure to meet a non-functional system requirement may make the whole system unusable
• Non-functional product requirements


  • "Spectators must be able to watch a match without prior registration and without prior knowledge of the match" (Usability Requirement)
  • "The system must support 10 parallel tasks" (Performance Requirement)
  • "The operator must be able to add new games without modifications to the existing system" (Supportability Requirement)
  • "The system shall allow one hundred thousand hits per minute on the website" (Performance Requirement)
  • "The system shall not have down time of more than one second for continuous execution of one thousand hours" (Reliability Requirement)
• Organizational requirements


  Requirements related to the system development process, deliverable documents, and sub-contracted work

  
• Organizational requirements


  • "The system development process and deliverable documents shall conform to the MIL-STD-2167A"
  • "Any development work sub-contracted by the development organization shall be carried out in accordance with Capability Maturity Model"
• External requirements


  Requirements related to ethical, legislative, privacy, and safety constraints
• External requirements


  • "The system shall not disclose any personal information about members of the library system to other members except system administrators"
  • "The system shall comply with the local and national laws regarding the use of software tools"
• Chances of conflicts within non-functional requirements are fairly high, because information is coming from different stakeholders
• Non-functional requirements should be highlighted in the requirements document, so that they can be used to build the architecture of the software product (Design Goals)
• Metrics for non-functional requirements


  Quantitative measures that can be used to objectively test non-functional requirements, such as speed, size, ease of use, reliability, robustness, and portability
• The cost of quantitatively verifying each non-functional requirement may be very high