University:
California State University, Northridge
Course:
COMP 380/L | Introduction to Software Engineering and Lab
Academic year:

2011
Views:

281

Pages:

17
Author:

georgieenfeu57v

Requirements Engineering Part 3 Requirements specification • Thee p process ocess o of writingg do don thee use user and a d system sys e requirements in a requirements document. • User requirements have to be understandable by end‐ users and customers who do not have a technical background. • System S t requirements i t are more detailed d t il d requirements i t and may include more technical information. • The requirements may be part of a contract for the system development – It is therefore important that these are as complete as possible. Ways of writing a system requirements specification f Notation Description Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured language natural The requirements are written in natural language on a standard form or template Each field provides information about an aspect of the template. requirement. Design description This approach uses a language like a programming language, but with more languages abstract features to specify the requirements by defining an operational model of the system. system This approach is now rarely used although it can be useful for interface specifications. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. used Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract Requirements and design • In p principle, p , requirements q should state what the system should do and the design should describe how it does this. • In practice, requirements and dd design are inseparable bl – A system architecture may be designed to structure the requirements; – The system may inter‐operate with other systems that generate design requirements; – The Th use off a specific ifi architecture hit t to t satisfy ti f non‐functional f ti l requirements may be a domain requirement. – This may be the consequence of a regulatory requirement. Natural language specification • Requirements are written as natural language sentences supplemented by diagrams and tables. • Used for writingg requirements q because it is expressive, intuitive and universal. This means that the requirements can be understood by users and customers. Guidelines for writing requirements • Invent a standard format and use it for all requirements. • Use language in a consistent way. Use shall for mandatory d requirements, should h ld for f d desirable bl requirements. • Use text highlighting to identify key parts of the requirement. p jargon. j g • Avoid the use of computer • Include an explanation (rationale) of why a requirement is necessary. Problems with natural language • Lack of clarity – Precision is difficult without making the document difficult to read. • Requirements confusion – Functional and non‐functional requirements tend to be mixed‐up. i d • Requirements amalgamation – Several S l diff differentt requirements i t may be b expressed d together. t th Example requirements for the insulin pump software f 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 • An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. • This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements. Form‐based Form based specifications • • • • Definition of the function or entity. Description of inputs and where they come from. Description of outputs and where they go to to. Information about the information needed for the computation and other entities used. • Description of the action to be taken. appropriate) • Pre and post conditions (if appropriate). • The side effects (if any) of the function. A structured specification of a requirement for f an insulin l pump A structured specification of a requirement for f an insulin l pump Tabular specification • Used to supplement natural language. • Particularly useful when you have to define a number of p possible alternative courses of action. • For example, the insulin pump systems bases its computations p on the rate of change g of blood sugar g level and the tabular specification explains how to calculate the insulin requirement for different scenarios. Tabular specification of computation f an insulin for l pump Condition Action Sugar level falling (r2 < r1) CompDose = 0 S Sugar l level l stable t bl (r2 ( 2 = r1) 1) C CompDose D =0 Sugar level increasing and rate of CompDose = 0 increase decreasing ((r2 – r1) < (r1 – r0)) Sugar level increasing and rate of CompDose = increase stable or increasing round ((r2 – r1)/4) ((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then CompDose = MinimumDose Requirements engineering processes • The p processes used for RE varyy widelyy depending p g on the application domain, the people involved and the organisation developing the requirements. • However, However there are a number of generic activities common to all processes – – – – Requirements elicitation; R Requirements i analysis; l i Requirements validation; Requirements management. • In practice, RE is an iterative activity in which these processes are interleaved. A spiral view of the requirements engineering process Requirements elicitation and analysis • Sometimes called requirements q elicitation or requirements q discovery. • Involves technical staff working with customers to find out about b t the th application li ti domain, d i the th services i that th t the th system t should provide and the system’s operational constraints. • Mayy involve end‐users,, managers, g , engineers g involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

Requirements Engineering, Part 3

Requirements Engineering, Part 3 - Page 3

Requirements Engineering, Part 3 - Page 4

Requirements Engineering, Part 3 - Page 5

Requirements Engineering, Part 3 - Page 6

Requirements Engineering, Part 3 - Page 7

Requirements Engineering, Part 3 - Page 8

Requirements Engineering, Part 3 - Page 9

Requirements Engineering, Part 3 - Page 10

Requirements Engineering, Part 3 - Page 11

Requirements Engineering, Part 3 - Page 12

Requirements Engineering, Part 3 - Page 13

Requirements Engineering, Part 3 - Page 14

Requirements Engineering, Part 3 - Page 15

Requirements Engineering, Part 3 - Page 16

Requirements Engineering, Part 3 - Page 17

of 17

Description

Free up your schedule!

Take 5 seconds to unlock