1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking

1

Requirements/Systems analyst

• Person performing the tasks of determining the requirements for a proposed software system– (problem analysis) breaking down what the

customer wants into discrete requirements

2

Requirements

• Goal of requirements phase– understand the customer’s problems and needs

• What is requirements?– An expression of desired behaviour

– Deals with objects/entities, states they can be in, and functions that are performed to change state or object characteristics

– Designates what behaviour the customer wants without saying how the behaviour will be realised

3

Specification and Design

• Specification makes decisions on which requirements will be fulfilled by our software system– As opposed to those that are addressed by

special purpose hardware devices, by other software systems or by human operator or users

• In design, a plan is devised as to how the specified behaviour will be implemented

4

Requirements process

5

Requirements Process - Elicitation

• Collecting the user requirements by:– Asking questions– Examining current behaviour– Demonstrating similar systems

6

Requirements Process - Analysis

• Understanding and modelling the desired behaviour– Modelling or prototyping the requirements helps us to

better understand the required behaviour

– Also raises additional questions about what the customer wants to happen in certain situations

• May expose problems or omissions in our models that cause us to revisit the customer and revise our models

7

Requirements Process - Specification

• Documenting the behaviour of the proposed software system– Requirements are well understood– Then it is decided which parts of the required

behaviour will be implemented in this software system

8

Requirements Process - Validation

• Checking that our specification matches the user’s requirements– Matches developer’s specifications with user’s

expectations of the final product

• May expose problems or omissions in our specifications that cause us to revisit the customer and revise our specifications

9

Requirements Process – Software Requirements Specifications

• Eventual outcome of the requirements process

• Is used to communicate to the other software developers (designers, testers, maintainers) how the final product ought to behave

10

Requirements Elicitation

• Critical part of the process

• Must use a variety of the techniques to determine what the users and the customers really want

• Discussion with everyone who has a stake in the system and coalescing these different views into a coherent set of requirements

11

Stakeholders in Requirements Elicitation Process

1. Clients

2. Customer

3. Users

4. Domain Experts

5. Market Researchers

6. Lawyers or auditors

7. Software engineers or other technology experts

12


• Clients– Pay for software to be developed– Ultimate stakeholders as they have final say on what product

does

• Customers– Buy software after it is developed

• Users– Experts on how current system works (most useful features,

features that need improvement)– Need to understand particular needs of special groups

(differently-abled individuals, persons unfamiliar with computers, expert users)

13


• Domain experts– Familiar with the problem that software must automate

(financial expert for a financial package, meteorologist for software to model weather)

– Also know about kinds of environment to which product will be exposed

• Market Researchers– Conduct surveys to determine future trends and

potential customers’ needs

14


• Lawyers/auditors– Familiar with government, safety or legal requirements

(tax expert ensures payroll package adheres to tax law, experts on standards which are relevant to product’s functions)

• Software Engineers/other technology experts– Ensures that the product is technically and economically

feasible– Educate customer about innovative technology,

recommend new functionality taking advantage of these technologies, and can estimate cost and development time

15

Techniques for Eliciting Requirements

1. Interviewing stakeholders

2. Reviewing available documentation

3. Observing current system (if one exists)

4. Apprenticing with users

5. Interviewing users/stakeholders in groups

6. Using Domain-specific strategies

7. Brainstorming

16


• Interviewing stakeholders– To capture the many views of the system and how it

should work

• Reviewing available documentation– Documented procedures of manual tasks– Specifications or user manuals of automated system

• Observing current system (if one exists)– Gather objective information about how users perform

their tasks– Better understand the system that the developers are

about to automate or change

17


• Apprenticing with users– Learn more about users’ tasks in more detail as the user

performs them

• Interviewing users/stakeholders in groups– So that they will be inspired by one another’s ideas

• Using domain-specific strategies– To ensure that stakeholders consider specific types of

requirements that are relevant to their particular situations

• Brainstorming with current and potential users about how to improve the proposed product

18

Types of Requirements – Functional Requirements

• Describes a required behaviour in terms of required activities– e.g. reactions to inputs, states of each entity

before and after an activity occurs

• Defined boundaries of a solution space for our problem– Solution space is the set of possible ways that

software can be designed to implement the requirements

19

Types of Requirements – Quality / Non-Functional Requirements

• Describes some quality characteristic that the software solution must posses– e.g. fast response time, ease of use, high

reliability and low maintenance costs

• Design criteria that can be optimised and used to choose among alternative implementations of functional requirements

20

Make Requirements Testable

• Make requirements testable so the conclusion of whether or not a proposed solution meets the requirement, must not vary according to who is doing the evaluation

• Fit criteria– Objective standards for judging whether a

proposed solution satisfies the requirements

21

Constraints on Requirements – Design Constraints

• Design constraint– Design decision that has already been made and that

restricts the set of solutions to our problem• e.g. choice of platform or interface components

• Process constraint– Restriction on the techniques or resources that can be

used to build the system• e.g. customer may insist that we use agile methods, so that

they can use early versions of the system while we continue to add features

22

Requirements Problem - Conflict

• May encounter conflicting ideas of what requirements ought to be, when eliciting from stakeholders

• Possible solutions are– Ask customer to prioritise requirements– Negotiation

23

Conflict Solutions – Customer prioritises requirements

• Helps customer reflect on which of requested services and features are most essential

• Loose prioritisation scheme separates requirements into 3 categories– Essential Requirements that absolutely must be met

– Desirable Requirements that are highly desirable but not necessary

– Optional Requirements that are possible but could be eliminated

24

Conflict Solutions – Negotiation

• Requires skills, patience and experience in finding mutually acceptable solutions

• With effective negotiation, stakeholders will– understand and appreciate each other’s

fundamental needs and– strive for a resolution that satisfies everyone

25

Different Purposes of Requirements

Requirements analysts and their clients

To explain their understanding of how the system would behave

Designers As constraints on what would be considered an acceptable solution

Test team To derive a suite of acceptance tests

Maintenance team To help ensure that the system enhancements do not interfere with the system’s original intent

26

Requirements Documents1. Requirements Definition

– Aimed at a business audience, such as clients, customers and users– Complete listing of everything customer wants to achieve– Written entirely in terms of environment, describing how the

environment will be affected by the proposed system

2. Requirements Document– Aimed at a technical audience, such as designers, testers and

project managers– Restates requirements as a specification of how proposed system

will behave– Written entirely in terms of environment, except that refers solely

to environmental entities that are accessible to the system via its interface

27

Characteristics of Requirements

1. Correctness

2. Consistency

3. Unambiguity

4. Completeness

5. Feasibility

6. Relevance

7. Testability

8. Traceability

28


1. Correctness• Developer and customer should ensure conformity to

our understanding of the requirements

2. Consistency• No conflicting requirements, as inconsistent

requirements cannot be satisfied simultaneously

3. Unambiguity• Multiple readers of requirements should have

different but valid interpretations

29


4. Completeness• Set of requirements is defined as complete if it

specifies required behaviour and output for all possible inputs in all possible states under all possible constraints

• Externally complete if all states, state changes, inputs, products, and constraints are described by some requirement

• Internally complete if there are no undefined terms among the requirements

30

Characteristics of Requirements5. Feasibility

• Existence of a solution to customer’s need

6. Relevance• Indirectly related to customer’s need or may restrict developers

unnecessarily

7. Testability• Existence acceptance tests that would clearly demonstrate whether

the eventual product meets the requirements

8. Traceability• Organisation of requirements for easy reference• There should be correspondence between every entry in the

requirement definition and requirements specification, and vice versa

31

Purpose of characteristics

• Help in making the decision when we have collected enough information

• Also when we need to learn more about what a particular requirement means

32

Purpose of characteristics

• The degree to which we want to satisfy these characteristics will affect:– Type of information that we gather during

requirements elicitation, and how comprehensive we want to be

– Specification language we choose to express the requirements and the validation and verification checks that we eventually perform to assess the requirements