3. Focus on functional rather than non-functional requirements such as reliability and security

B.2 Throw-away prototypes

C.1 Prototypes should be discarded after development as they are not a good

basis for a production system:

1. 2. 3. 4.

It may be impossible to tune the system to meet non-functional requirements; Prototypes are normally undocumented;

The prototype structure is usually degraded through rapid change;

The prototype probably will not meet normal organisational quality standards.

2.5.3 Incremental delivery

1. Rather than deliver the system as a single delivery, the development and delivery is broken

down into increments with each increment delivering part of the required functionality.

2. User requirements are prioritised and the highest priority requirements are included in early

increments.

3. Once the development of an increment is started, the requirements are frozen though

requirements for later increments can continue to evolve.

B.1 Incremental delivery advantages

1. Customer value can be delivered with each increment so system functionality is available

earlier.

2. Early increments act as a prototype to help elicit requirements for later increments. 3. Lower risk of overall project failure.

4. The highest priority system services tend to receive the most testing.

B.2 Incremental delivery problems

C.1 Most systems require a set of basic facilities that are used by different parts

of the system.

As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments.

C.2

The essence of iterative processes is that the specification is developed in conjunction with the software.

However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract.

2.5.4 Boehm’s spiral model

Page 17 of 91

A.1 Concept

1. Process is represented as a spiral rather than as a sequence of activities with backtracking. 2. Each loop in the spiral represents a phase in the process.

3. No fixed phases such as specification or design - loops in the spiral are chosen depending on

what is required.

4. Risks are explicitly assessed and resolved throughout the process.

Determine objectivesalternatives andconstraintsEvaluate alternativesidentify, resolve risksRiskanalysisRiskanalysisRiskanalysisREVIEWRequirements planLife-cycle planRiskanaylsisProto-type 1Concept ofOperationPrototype 3Prototype 2Opera-tionalprotoypeSimulations, models, benchmarksS/WrequirementsProductdesignDevelopmentplanIntegrationand test planPlan next phaseCodeUnit testDesignV&VIntegrationtestAcceptancetestDevelop, verifyServicenext-level productRequirementvalidationDetaileddesign

A.2 Spiral model sectors

B.1 B.2 B.3 B.4

Objective setting

Risk assessment and reduction Development and validation Planning

Specific objectives for the phase are identified.

Risks are assessed and activities put in place to reduce the key risks.

A development model for the system is chosen which can be any of the generic models. The project is reviewed and the next phase of the spiral is planned.

A.3 Spiral model usage

1. Spiral model has been very influential in helping people think about iteration in software

processes and introducing the risk-driven approach to development.

2. In practice, however, the model is rarely used as published for practical software

development

Page 18 of 91

2.6 Key points

1. Software processes are the activities involved in producing a software system. Software

process models are abstract representations of these processes.

2. General process models describe the organization of software processes. Examples of these

general models include the ‘waterfall’ model， incremental development, and reuse-oriented development.

3. Requirements engineering is the process of developing a software specification.

4. Design and implementation processes are concerned with transforming a requirements

specification into an executable software system.

5. Software validation is the process of checking that the system conforms to its specification

and that it meets the real needs of the users of the system.

6. Software evolution takes place when you change existing software systems to meet new

requirements. The software must evolve to remain useful.

7. Processes should include activities to cope with change. This may involve a prototyping

phase that helps avoid poor decisions on requirements and design.

8. Processes may be structured for iterative development and delivery so that changes may be

made without disrupting the system as a whole.

2.7 Excercises(Homework): P54

2.1, *2.4

Page 19 of 91

Chapter 3 (4) Requirements Engineering

3.1

1. 2. 3. 4. 5. 6. 7.

Topics covered

Functional and non-functional requirements The software requirements document Requirements specification

Requirements engineering processes Requirements elicitation and analysis Requirements validation Requirements management

3.2 Requirements engineering

3.2.1 What is a requirement?

B.1

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification B.2 This is inevitable as requirements may serve a dual function

? May be the basis for a bid for a contract - therefore must be open to interpretation ? May be the basis for the contract itself - therefore must be defined in detail ? Both these statements may be called requirements

3.2.2 Requirements engineering

? The process of establishing the services that the customer requires from a system and the

constraints under which it operates and is developed

? The requirements themselves are the descriptions of the system services and constraints that

are generated during the requirements engineering process

3.2.3 Types of requirement

B.1

User requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers

B.2 System requirements

A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor

Page 20 of 91