Software Engineering: Requirements Analysis

Requirements Analysis

• A software engineering task that bridges the gap between system engineering and software design
• Divided into 5 areas of effort: problem reorganization, evolution and synthesis, modeling, specification, and review

Requirements Validation

• Concerned with demonstrating that the requirements define the system that the customer really wants
• Importance: fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error
• Requirements checking includes:
  • Validity: Does the system provide the functions that best support the customer’s needs?
  • Consistency: Are there any requirements conflicts?
  • Completeness: Are all functions required by the customer included?
  • Realism: Can the requirements be implemented given available budget and technology?
  • Verifiability: Can the requirements be checked?

Requirements Validation Techniques

• Requirements reviews: systematic manual analysis of the requirements
• Prototyping: using an executable model of the system to check requirements
• Test-case generation: developing tests for requirements to check testability

Requirements Reviews

• Regular reviews should be held while the requirements definition is being formulated
• Both client and contractor staff should be involved in reviews
• Reviews may be formal (with completed documents) or informal
• Rules established for preparation and participation
• Agenda suggested to cover important points and to allow for brainstorming
• Meeting controlled by facilitator (customer, developer, or outsider)
• Definition mechanism (flip charts, stickers, electronic device, etc.) is used
• Goal is to identify problem, propose elements of solution, negotiate different approaches, and specify a preliminary set of solution requirements

Quality Function Deployment (QFD)

• Emphasizes an understanding of what is valuable to the customer
• Translates customer needs into technical software requirements
• Uses customer interviews, observation, surveys, and historical data for requirements gathering
• Customer voice table (contains summary of requirements) includes:
  • Normal requirements (must be present in product for customer to be satisfied)
  • Expected requirements (things like ease of use or reliability of operation)
  • Exciting requirements (features that go beyond the customer's expectations)

Requirement Analysis

• The process of understanding customer needs and expectations from a proposed system or application
• A well-defined stage in the SDLC model
• Example requirements:
  • User shall be able to search either all of the initial set of databases or select a subset
  • System shall provide appropriate viewers for the user to read documents in the document store
  • Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area

Non-Functional Requirements

• Define system properties and constraints (e.g. reliability, response time, and storage requirements)
• Constraints include I/O device capability, system representations, etc.
• Process requirements may also be specified (mandating a particular CASE system, programming language or development method)
• Non-functional requirements may be more critical than functional requirements

Requirements Engineering Processes

• Goal is to create and maintain a system requirements document
• Overall process includes four high-level requirement engineering sub-processes:
  • Assessing whether the system is useful to the business (feasibility study)
  • Discovering requirements (elicitation and analysis)
  • Converting these requirements into some standard form (specification)
  • Checking that the requirements actually define the system that the customer wants (validation)
• The process of managing the changes in the requirements is called requirement management