Objectives

  • Eliciting requirements from customers
  • Modelling requirements
  • Reviewing requirements to ensure their quality
  • Documenting requirements for use by the design and test teams

The Requirements Process

A requirement is an expression of desired behaviour

Requirements deal with:

  • Objects/Entities
  • The state they can be in
  • Functions that are performed to change states or object characteristics

Requirements focus on the customer needs, not on the solution or implementation
Designate what behaviour, without saying how that behaviour will be realised

Why Are Requirements Important

Top factors that caused projects to fail:

  • Incomplete requirements
  • Lack of user involvement
  • Unrealistic expectations
  • Lack of executive support
  • Changing requirements and specification
  • Lack of planning
  • System no longer needed

Some part of the requirements process is involved in almost all of these cases
Requirements errors can be very expensive if not detected early

Process for Capturing Requirements

  • Performed by the req. analyst or system analyst
  • The final outcome is a Software Requirements Specification (SRS) document

Agile Requirements Modelling

  • If requirements are tightly coupled and very complex, a “heavy” process that emphasizes up-front modelling can be used
  • If the requirements are uncertain or flexible, agile methods are, in man cases, a better approach
  • Agile methods gather and implement the requirements in increments, such as in XP:
    • The requirements are defined as we build the system
    • Little planning or designing for possible future requirements
    • Encodes the requirements as test cases that eventually the implementation must pass

Elicitation

Customers do not always understand what their needs and problems are, as such it is importnat to discuss the requirements with everyone who has a stake in the system.

Stakeholders

  • Clients pay for the software to be developed
  • Customers buy the software after it is develooped
  • Users use the system
  • Software Engineers or other technology exports develop the software
  • Domain experts are familiar with the problem the software must automate
  • Market researchers conduct surveys to determine future trends and potential customers
  • Lawyers or auditors are familiar with government, safety or legal requirements

Means of Eliciting Requirements

  • Interviewing users/stakeholders
  • Reviewing available documentation
  • Observing the current system (if one exists)
  • Apprenticing with users to learn about their tasks
  • Using domain-specific strategies

Using Viewpoints to Manage Inconsistency

  • No need to resolve inconsistencies early in the requirements process
  • Stakeholders’ views are documented and maintained as separate viewpoints
  • Inconsistencies are noted but not addressed until there is enough information for a decision

Types of Requirements

  • Functional Requirement - Describes required bheaviour in terms of required activities
  • Quality/Non-Functional Requirement - Describes some quality characteristic that the software must possess
  • Design Constraint - A design decision such as choiceof platform or interface components
  • Process Constraint - A restriction on the techniques or resources that can be used to build the system

Making Requirements Testable

Fit criteria form objective standards for judging whether a proposed solution satisfies the requirements

  • It is easy to set fit criteria for quantifiable requirements
  • It is harder to do so for qualitative requirements

To ensure requirements are testable, there should be a quantitative description for each advert and adjective.
Pronouns should be replaced with specific names of entities.
Make sure that every noun is defined in exactly one place in the requirements documents.

Resolving Conflicts

Different stakeholders have different sets of requirements - this can lead to conflicting ideas.
Requirements must be prioritised:

  • Essential requirements that absolutely must be met
  • Desirable requirements that are not strictly necessary
  • Optional requirements that can be eliminated

Two Kinds of Requirements Documents

  • Requirements Definition - A complete listing of what the customer wnats to achieve
    • Describes the entities in the environment where the system will be installed
  • Requirements specification - restates the requirements as a specification of how the proposed system shall behave

Ideal Characteristics of Requirements

  • Correct
  • Consistent
  • Unambiguious
  • Complete
  • Feasible
  • Relevant
  • Testable
  • Traceable

Definition and Specification

  • Outline the general purpose and scope of the system, including relevant benefits, objectives and goals
  • Describe the background and the rationale behind proposal for the new system
  • Describe the essential characteristics of an acceptable solution
  • Describe the environment in which the system will operate
  • List any assumptions we make about how the environment behaves

Documenting Process Steps

Restate the required functionality in terms of the interfaces’ inputs and outputs, eg:

  • The sources of inputs
  • The destinations of outputs
  • The value ranges
  • Data format of input and output data
  • Data protocols
  • Window formats and organisation
  • Timing constraints

Devise fit criteria for each of the customer’s quality requirements

Level of Specification

A survey in 1995 showed that one of the problems with requirement specifications was the uneven level of specification

  • Different writing styles
  • Different in experience
  • Different formats
  • Overspecifying requirements
  • Underspecifying requirments

Recommendations to reduce unevenness:

  • Write each clause so that it only contians one requirement
  • Avoid having one requirement refer to another requirement (they should also be atomic)
  • Collect similar requirements together

Hidden Assumptions

Two types of environmental behaviour of interest:

  • Desired behaviour to be realised by the proposed system
  • Existing behaviour that is unchanged by the proposed system (often called assumptions/domain knowledge)

Requirements Documentation IEEE Standard fo SRS Organised by Objects

1. Introduction to the Document
    1.1 Purpose of the Product
    1.2 Scope of the Product
    1.3 Acronyms, Abbreviations, Definitions
    1.4 References
    1.5 Outline of the rest of the SRS
2. General Description of Product
    2.1 Context of Product
    2.2 Product Functions
    2.3 User Characteristics
    2.4 Constraints
    2.5 Assumptions and Dependencies
3. Specific Requirements
    3.1 External Interface Requirements
    3.1.1 User Interfaces
    3.1.2 Hardware Interfaces
    3.1.3 Software Interfaces
    3.1.4 Communications Interfaces
    3.2 Functional Requirements
    3.2.1 Class 1
    3.2.2 Class 2
    …
    3.3 Performance Requirements
    3.4 Design Constraints
    3.5 Quality Requirements
    3.6 Other Requirements
4. Appendices

Process Management and Requirements Traceability

Process managamenet is a set of procedures that track:

  • The requirements that define what the system should do
  • The design modules that are generated from the requirement
  • The program code that implements the design
  • The tests that verify the functionality of the system
  • The documents that describe the system