Software Requirements

[jimin-kiim]

• FURPS+
• NFR
• specifying FR
• SRS and Requirements Review

[jimin-kiim]

FURPS+

• Functional Requirements (FR)
  • describe functionality or system services
  • how the system should react to particular inputs
  • how the system should behave in particular situations
• Non-functional Requirements (NFR)
  • describe properties of the system of the domain
  • Quality Attributes (URPS): Usability, Reliability, Performance, etc.
  • Constraints (+): OS, hardware, development languag, etc.
  • NFR may be more critical than FR. If these are not met, the system is useless.

[jimin-kiim]

NFR

Characteristic

• NFR may affect the overall architecture of a system
  • e.g., performance requirements -> organize the system to minimize communication between components
• NFR may generate a number of related FR
  • e.g., security requirement
• NFR may generate requirements restricting existing requirements

Classifications

• Product requirements
  • specify that the delivered product must behave in a particular way
  • e.g., execution speed, reliability, etc.
• Organisational requirements
  • consequence of organisational policies and procedures
  • e.g., process standards used, implementation requirements, etc.
• External requirements
  • external to the system and its development process
  • e.g., regulatory requirements, legislative requirements, etc.

Verifiable Requirements

• hard-to-verify vs verifiable requirements exist
• verifiable requirements can be measured with several properties
  • speed, size, ease of use, reliability, robustness, portability

[jimin-kiim]

Specifying FR

• Declarative Statements(Traditional Approach)
• Use Cases(Newer technique)
  • well suited for interactive systems
  • they do not from the complete SRS, only the functionality part.

Use Cases (UCs)

• describe interactions between actors & system
• focuses on external behavior
• basically a textual form
  • diagrams are mostly to support
• also useful in requirements elicitation
  • users like and understand the story telling from and can react to it easily
• actor: a person or a system that interacts with the system to achieve a goal
  • primary actor: the main actor who initiates a UC
  • e.g., user of an ATM - goal: getting money
  • e.g, data entry operator - goal: performing transaction
• scenario
  • describe a concrete set of actions
  • the set of actions are performed to achieve a goal under some conditions
  • main success scenario: when things go normally and the goal is achieved
  • alternate scenarios: when things go wrong and goals cannot be achieved

[jimin-kiim]

SRS and Requirements Review

Requirements Validation

• there are a lot of room for misunderstanding
• it's expensive to fix requirements defects later
  • so must try to remove most errors in SRS
• most common errors
  • Omission(30), Inconsistency(10-30), Incorrect fact(10-30), Ambiguity(5-20)

Software Requirement Specification (SRS)

• a description of a software system to be developed
• aka. RAD(Requirements Analysis Document)
• can be written in various formats

Desirable properties of requirements

• unambiguous: should have only one interpretation
• correct: should be the one that stakeholder really want
• complete: should include all the requirements
• consistent: no subset has conflict
• feasible: technically achievable
• traceable: traces to its source and implementation

Requirements Review

• SRS is reviewed by a group of people
  • author, client, user, development team
  • must include client and user
• can catch 40-80% of requirements errors

SRS and Review in Development Process

• done in Requirements Elicitation(-> Use case model), Analysis stage(-> Analysis Model)
  • Requirements Elicitation: defining the system in terms that can be understood by the customer
  • Analysis stage: defining the system in terms that can be understood by developer
• Questions need to be answered during requirements elicitation and analysis
  • How can we identify the purpose of a system?
  • What is inside and what is outside the system?

[jimin-kiim]

Quality Attribute Scenario

• Stimulus
  • a condition that requires a response when it arrives at a system
• Source of the stimulus
  • This is some entity (a human, a computer system, or any other sensors/actuators) that generated the stimulus
• Artifact
  • Some artifact is stimulated. This may be a collection of systems, the whole system, or some piece or pieces of it
• Environment
  • The stimulus occurs under certain conditions.
• Response
  • The response is the output generated or activity undertaken as the result of the arrival of the stimulus
• Response Measure
  • When the response occurs, it should be measurable in some fashion so that the requirement can be tested.

Example

• Users initiate transactions under normal operations.
• The system processes the transactions with an average latency of two seconds.
• The developer wishes to change the user interface by modifying the code at design time.
• The modifications are made with no side effects within three hours.