Chapter 4 Requirements Engineering Chapter 4 Requirements engineering1.

S

Chapter 4 Requirements Engineering

Chapter 4 Requirements engineering1

Requirements Engineering

May be used in all software Development models Waterfall Agile Reuse Other


Requirements engineering processes

Vary widely.

Common processes Requirements elicitation; Requirements analysis; Requirements validation; Requirements management.

Typically iterative/interleaved.


Requirements Form

Document (Traditional)

Agreement (Agile)


What is a Requirement?

What is needed of the system Allow storage of name, address, phone, SSS for

employees Phone must allow for international number

Valid? Number of digits for SSS GUI toolset Programming Language


Levels of requirement

User requirements High level For customers Their terminology

System requirements Detailed For development For contacts


User and system requirements


Requirement Types

Functional Requirements Features Specific functionality More from users

Non Functional Requirements Broad concepts Apply to large functionality Performance, Capacity, Reliability, Security, Availability More from developers


Types of Requirements

Functional requirements Functionality needed

Generate map of voters Compute tips for tax reports Generate report of sales by location

Non-functional requirements Constraints

Speed Reliability Uptime Location (from any browser)


Functional Requirements

High level Calculate wages per employees

Medium Calculate standard wages Calculate tips Calculate overtime

Low Calculate standard tips Calculate distributed tips


Functional RequirementChallenge

Lack of detail

Lack of clarity


Non-functional requirements

Scope Affect large portions of project

Not specific to functionality Reliability Availability Response time Capacity (number of records) Constraints (work with an existing system) IDE Programming language Development method Coding Standards


Non-functional – Functional Link

Non functional requirement may generate many functional requirements Security

Logons Password recovery


Types of nonfunctional requirement


Measurability

Non functional requirements must be measurable


Metrics for specifying nonfunctional requirements


Property Measure

Speed Processed transactions/secondUser/event response timeScreen refresh time

Size MbytesNumber of ROM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure

Portability Percentage of target dependent statementsNumber of target systems

Examples

All error messages will contain enough identification to locate source of problem in code.

All error messages will lead to a solution

No software installation will require system reboot.

All names in code will be self explanatory

All functionality will appear in menus or on dialogs.

All functionality can be accessed via menu or keystroke.


Domain requirements

Operational environment Train brake control system Temperature range Humidity range Gradient range


Software Requirements Doc

Agreed upon plan Critical for waterfall

review may be after extended period Less critical / formal for agile

Review/change will come soon anyway


Agile methods and requirements

Requirements Document Waste of Time Inherently out of date Replaced by user stories


The structure of a requirements document


Chapter Description

Preface This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version.

Introduction This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software.

Glossary This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader.

User requirements definition

Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified.

System architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.

The structure of a requirements document

Chapter Description

System requirements specification

This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined.

System models This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models.

System evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system.

Appendices These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data.

Index Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on.


Users of a requirements document


Requirement SpecificationFormats

Natural Language

Structured natural language

Design Description language

Graphical

Mathmatical


Natural language specification

Natural language sentences supplemented by diagrams and tables.

Characteristics expressive, Intuitive universal


Guideline

Invent a standard format.

Consistent Language Shall vs. Should

Highlighting, Underlining.

Avoid computer jargon.

Include rationale for requirements

Example requirements for the insulin pump software

system


3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.)

Structured specifications

Standard format

Predictable

Forces spec completion

May contain natural language

May be too rigid Standard sequence Tabular


A structured specification of a requirement for an

insulin pump


Tabular specification of computation for an insulin

pump


Condition Action

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate of increase decreasing ((r2 – r1) < (r1 – r0))

CompDose = 0

Sugar level increasing and rate of increase stable or increasing ((r2 – r1) ≥ (r1 – r0))

CompDose = round ((r2 – r1)/4)If rounded result = 0 then CompDose = MinimumDose

Requirements ElicitationProcess

Discovery

Classification/ Organization

Prioritization/ Negotiation

Documentation


Elicitation - Participants

Development personnel System engineers Developers Managers

Customer Managers Engineers, Domain experts Trade unions


Elicitation Problems

Stakeholders limited understanding of needs Assume basic knowledge of their domain Availability

Multiple stakeholders Different priorities Conflicting requirements

Which stakeholder Manager User

Changing business Generally Due to the system itself


Discovery Approaches

Interview

Scenario

Use Case

Ethnography


Types of Interviews

Types of interview Closed

list of questions Open

various issues explored.


Interviews in practice

Be prepared with questions

BUT, start with open ended questions

Bring up issues where you expect will cause problems

Scenarios

Real-life examples of how a system can be used.

Include description of the starting situation description of the normal flow of events description of what can go wrong Information about other concurrent activities description of the state when the scenario finishes

Scenario for collecting medical history in MHC-

PMS


Use cases

UML Actors, Interaction

Should describe all possible interactions with the system.

Graphical or tabular


Use cases for the MHC-PMS


Ethnography

Based on interviews Watching people work Often < 1hr

Capture Interactions Activities Data Forms Pressures


Ethnography

Model the work environment Process flow Interactions Data Context


Ethnography

Useful for Understanding environment

People involved Current Processes Implicit environment Workflow Implicit aspects of work that people don’t explain Understanding without formal explanation

Shows that work is usually richer and more complex than suggested by simple system models.


Pros/Cons

Pros Actual work not concept Develops thorough knowledge of users, environment

Cons Focused only on existing process Focused only on needs of users


Focused ethnography

Combines ethnography with prototyping

Prototype can be evaluated in the work environment


Requirements checking

Validity. Does the system provide the functions which 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. Covered in Chapter 2.

Test-case generation Developing tests for requirements to check

testability.


Requirements reviews

Regular

Client and contractor

Formal or informal


Review checks

Verifiability Is the requirement realistically testable?

Comprehensibility Is the requirement properly understood?

Traceability Is the origin of the requirement clearly stated?

Adaptability Can the requirement be changed without a large impact

on other requirements?


Requirements Management

Tracking changes to requirements New requirements Changed requirements Dropped Requirements

“Scope creep”


Requirements Management

Implicit part of agile development


Changing requirements

The business and technical environment of the system always changes after installation. New hardware necessary to interface the system with other systems business priorities change new legislation and regulations may be introduced Budgetary changes

The people who pay for a system and the users of that system are rarely the same people.


Changing requirements

Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory. The final system requirements are inevitably a

compromise between them and, with experience, it is often discovered that the balance of support given to different users has to be changed.


Chapter 4 Requirements Engineering Chapter 4 Requirements engineering1.

Documents

Transcript of Chapter 4 Requirements Engineering Chapter 4 Requirements engineering1.