Requirements Analysis: Luca Viganò

Requirements Analysis
Luca Vigan
Dipartimento di Informatica Universit di Verona
Ingegneria del SW, 11.03.11
Luca Vigan (Universit di Verona)
1 / 81
Objectives
To introduce the concepts of user and system requirements. To describe functional and nonfunctional requirements. To explain how software requirements may be organized in a requirements document.
See: Ian Sommerville. Software Engineering. Pearson Education Ltd.
2 / 81
Table of contents
Background/motivation The analysis and denition phase Structuring requirements A concrete example of a simplied product sketch Conclusions
3 / 81
Background/motivation
Outline
4 / 81
A welcome problem...
You have inherited 100 Million Euro and want to start your own airline company!
What system should your future IT-department design?
5 / 81
Well, there is some data to administer
Flights: Routes, times, seats, crew, food (rst class, vegetarian, ...)... Crew and support staff: Personal data, tasks, time plan, pay-roll, ... Customers: Reservations, accounts, Miles & More, meat-eater, ... Inventory: Airplanes, fuel, vegetarian food, deliveries (carrots, ...)
6 / 81
And dont forget
Planning programs (time and cost plans). Support for E-commerce:

Customer-to-business (C2B), e.g. buying tickets, checking status. Business-to-business (B2B), e.g. supply-chain management. Web pages (internal/external).
Building a system that is secure, redundant (fault tolerant), evolvable, . . . and this is only the beginning!
7 / 81
The analysis and denition phase
Outline
8 / 81
The context
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
First phase: requirements analysis and denition. Sometimes called requirements planning or requirements engineering.
9 / 81
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. N.B.: the term requirement is not used in the software industry in a consistent way: it may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specication. This is inevitable as requirements may serve a dual function:
May be the basis for a bid for a contract = must be open to interpretation. May be the basis for the contract itself = must be dened in detail.
Luca Vigan (Universit di Verona) Requirements Analysis Ingegneria del SW, 11.03.11 10 / 81
Requirements abstraction
If a company wishes to let a contract for a large software development project, it must dene its needs in a sufciently abstract way that a solution is not predened. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organizations needs. Once a contract has been awarded, the contractor must write a system denition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system. from: A.M. Davis, Software requirements: Objects, Functions, & States, Prentice Hall 1993.
Types of requirement
User requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System requirements: A structured document setting out detailed descriptions of the systems functions, services, and operational constraints. Denes what should be implemented so may be part of a contract between client and contractor.
12 / 81
Functional, non-functional, and domain requirements
Functional requirements: statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Non-functional requirements: constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements: requirements that come from the application domain of the system and that reect characteristics of that domain.
13 / 81
Functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do, but functional system requirements should describe the system services in detail.
14 / 81
Non-functional requirements
Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Dene system properties and constraints, e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specied mandating a particular CASE system, programming language, or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.
15 / 81
Types of non-functional requirements
16 / 81
Non-functional classications
Product requirements: requirements which specify that the delivered product must behave in a particular way, e.g. execution speed, reliability, etc. Organizational requirements: requirements which are a consequence of organizational policies and procedures, e.g. process standards used, implementation requirements, etc. External requirements: requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
17 / 81
Goals and requirements

Non-functional requirements may be very difcult to state precisely and imprecise requirements may be difcult to verify. Goal:
A general intention of the user such as ease of use. Goals are helpful to developers as they convey the intentions of the system users. Example: the system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized.
Veriable non-functional requirement:

A statement using some measure that can be objectively tested. Example: experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.
Requirements interaction
Conicts between different non-functional requirements are common in complex systems. Example: a spacecraft system.
To minimize weight, the number of separate chips in the system should be minimized. To minimize power consumption, lower power chips should be used. However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?
19 / 81
Domain requirements
Are derived from the application domain and describe system characteristics and features that reect the domain. Domain requirements may be new functional requirements, constraints on existing requirements, or dene specic computations. If domain requirements are not satised, the system may be unworkable. Possible problems: Understandability:
Requirements are expressed in the language of the application domain. This is often not understood by software engineers developing the system.
Implicitness:
Domain specialists understand the area so well that they do not think of making the domain requirements explicit.
Types of requirement more in detail: User requirements

Should describe functional and non-functional requirements in such a way that they are understandable by system users who dont have detailed technical knowledge. User requirements are dened using natural language, tables, and diagrams as these can be understood by all users. Problems with natural language: Lack of clarity: precision is difcult without making the document difcult to read. Requirements confusion: functional and non-functional requirements tend to be mixed-up. Requirements amalgamation: several different requirements may be expressed together.
Types of requirement more in detail: System requirements
More detailed specications of system functions, services and constraints than user requirements. They are intended to be a basis for designing the system. They may be incorporated into the system contract. System requirements may be dened or illustrated using system models discussed in the next weeks.
22 / 81
Structuring requirements
Outline
23 / 81
Lets return to the example: goal
24 / 81
Goal (cont.)
The goal: Specify the requirements as detailed as possible, but as abstract as possible. To understand what the product should do.
Otherwise programming is pointless! Exception: rapid prototyping to aid analysis itself.
As a contract with the customer. To plan the development. Many projects require a concrete product denition.
Companies, governments, most large companies... For instance, the term Pichtenheft is sometimes used in Germany to stress the legal aspects (Heft = fascicolo/quaderno, Picht = obbligo, sich verpichten= impegnarsi a fare qualcosa).
25 / 81
Planning is difcult
What does one want? The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difcult as establishing the detailed technical requirements... No other part of the work so cripples the resulting system if done wrong. No other part is more difcult to rectify later. (Brooks 1987) Compromises are necessary between different, contradictory user requirements. Example: Bank
26 / 81
Planning is difcult
What does one want? The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difcult as establishing the detailed technical requirements... No other part of the work so cripples the resulting system if done wrong. No other part is more difcult to rectify later. (Brooks 1987) Compromises are necessary between different, contradictory user requirements. Example: Bank customers want security. Bank employees want minimal restrictions and overhead. Delayed effects are difcult to predict. Example:
26 / 81
Planning is difcult
What does one want? The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difcult as establishing the detailed technical requirements... No other part of the work so cripples the resulting system if done wrong. No other part is more difcult to rectify later. (Brooks 1987) Compromises are necessary between different, contradictory user requirements. Example: Bank customers want security. Bank employees want minimal restrictions and overhead. Delayed effects are difcult to predict. Example: Inuence of the invention of the auto on
26 / 81
Planning is difcult
What does one want? The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difcult as establishing the detailed technical requirements... No other part of the work so cripples the resulting system if done wrong. No other part is more difcult to rectify later. (Brooks 1987) Compromises are necessary between different, contradictory user requirements. Example: Bank customers want security. Bank employees want minimal restrictions and overhead. Delayed effects are difcult to predict. Example: Inuence of the invention of the auto on the sexual behavior of American teenagers.
Requirements and design
In principle, requirements should state what the system should do and the design should describe how it does this. In practice, requirements and design are inseparable:
A system architecture may be designed to structure the requirements. The system may interoperate with other systems that generate design requirements. The use of a specic design may be a domain requirement.
27 / 81
Problems with natural language specication
Ambiguity: The readers and writers of the requirement must interpret the same words in the same way. Natural language is naturally ambiguous so this is very difcult. Over-exibility: The same thing may be said in a number of different ways in the specication. Lack of modularization: Natural language structures are inadequate to structure system requirements.
28 / 81
Alternatives to natural language specication

Structured natural language:
Approach depends on dening standard forms or templates to express the requirements specication.
Design description languages:

Approach uses a language like a programming language but with more abstract features to specify the requirements by dening an operational model of the system. Approach not now widely used although it can be useful for interface specications.
Graphical notations:
Graphical languages supplemented by text annotations help dene the functional requirements for the system. Use-case descriptions and sequence diagrams are commonly used nowadays.
Mathematical specications:
Unambiguous specications based on mathematical concepts such as nite-state machines or sets. However, most customers dont understand formal specications and are reluctant to accept them as a system contract.
Possible structuring of requirements analysis
Name Requirements analysis
Requirements specication
For whom Customer (Managers) Users Contract manager System architects Customer System architects Programmers System architect Programmers
Question addressed What is the problem (rough)? Answer: Product sketch in natural language (+gures) What is the problem (detailed)? Answer: Product denition Precise structured document Serves as contract What is the solution (rough)? Answer: System architecture
Software specication
30 / 81
Structuring requirements analysis an example
Product sketch: 1. The program should read les over the Internet. Product denition: 1.1. 1.2. 1.3. 1.3.1. The user can access and view les over the Internet. A le is given through a URL, typed in from the keyboard. Various types of URLs are supported. html means that the le is hyper-text... (Explanation of how are les loaded, displayed, browsed, ...)
Software specication: (Abstract description of the main browser routines, ...).
31 / 81
Unstructured text is poor. Example: Editor for a CASE Tool. 2.6 Grid facilities To assist in positioning entities on a diagram, the user may turn on a grid in either centimeters or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimeters. A grid option will be provided on the reduce-to-t view but the number of grid lines shown will be reduced to avoid lling the smaller diagram with grid lines. Problems:
The rst sentence mixes different requirements. Incomplete description (e.g. units used when turned on). Justication partially mixed with specication.
Structuring requirements: Better is to describe fundamental properties. . .

2.6 Grid Facilities 2.6.1 The editor shall provide a grid facility where a matrix of horizontal and vertical lines provides a background to the editor window. This grid shall be a passive grid where the alignment of entities is the users responsibility. Rationale: A grid helps the user to create a tidy diagram with well space entities. Although an active grid, where entities snap-to grid lines can be useful, the positioning is imprecise. The user is the best person to decide where entities should be positioned. 2.6.2 When used in reduce-to-t mode (see 2.1), the number of units separating grid lines must be increased. Rationale: If line spacing is not increased, the background will be cluttered with grid lines. Specication: ECLIPSE/WS/TOOLS/DE/FS Section 2.6
Structuring requirements: . . . and to describe basic operations

3.5.1 Adding nodes to a design 3.5.1.1 The editor shall provide a facility where users can add nodes of a specied type to a design. Nodes are selected (see 3.4) when they are added to the design 3.5.1.2 The sequence of actions should be as follows: (1) The user should select the type of node to be added (2) The user moves the cursor to the appropriate node position in the diagram and indicates that the node symbol should be added at that point. (3) The symbol may then be dragged to its nal position. Rationale: The user is the best person to decide where to position a node on the diagram. This approach gives the user direct control over node type selection and positioning. Specication: ECLIPSE/WS/TOOLS/DE/FS Section 3.5.1
Structuring requirements documents

No standard structure, but structuring is helpful and important.
The freedom of the requirements writer is limited by a predened template for requirements. All requirements are written in a standard way.
Some organizations have their own standards (see below). Can also depend on process model and the kind of system developed.
The terminology used in the description may be limited. The advantage is that the most of the expressiveness of natural language is maintained but a degree of uniformity is imposed on the specication.
Some common principles:

Describe goals, functionality, environment/use. Description should be abstract and avoid unnecessary commitments.
Form-based specication
Denition of the function or entity. Description of inputs and where they come from. Description of outputs and where they go to. Indication of other entities required. Pre and post conditions (if appropriate). The side effects (if any) of the function.
36 / 81
Example: Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: Safe sugar level. Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units. Inputs Current sugar reading (r 2), the previous two readings (r 0 and r 1) Source Current sugar reading from sensor. Other readings from memory. Outputs CompDose the dose in insulin to be delivered Destination Main control loop Action CompDose is 0 if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result is rounded to 0 then CompDose is set to the minimum dose that can be delivered. Requires 2 previous readings so that the rate of change of sugar level can be computed. Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin. Post-condition r 0 is replaced by r 1 then r 1 is replaced by r 2 Side-effects None
Tabular specication
Used to supplement natural language. Particularly useful when you have to dene a number of possible alternative courses of action. Example: Condition Sugar level falling (r 2 < r 1) Sugar level stable (r 2 = r 1) Sugar level increasing and rate of increase decreasing ((r 2 r 1) < (r 1 r 0)) Sugar level increasing and rate of increase stable or increasing ((r 2 r 1) (r 1 r 0)) Action CompDose = 0 CompDose = 0 CompDose = 0 CompDose = round ((r 2 r 1)/4) If rounded result = 0 then CompDose = MinimumDose
38 / 81
Graphical models
Graphical models are most useful when you need to show how state changes or where you need to describe a sequence of actions. Different graphical models explained in the next weeks.
39 / 81
Example: data-ow modeling
System modeled as data-transformer. Describes data as well as function input and output. Control ow not xed. Expresses only (very weak!) functional requirements.
More in detail: Data-Flow Diagrams

Data-ow diagrams (DFD) show the process steps in terms of the ow of data/information: how data/information ows along a sequence of computation steps. A simple and intuitive notation, which can be easily understood by the clients. It represents the functions/processes, the ow of information from one function to the other, the data stores, and the external agents.
Function or process Data flow

Luca Vigan (Universit di Verona) Requirements Analysis
External agent Permanent data store
41 / 81
DFD renement
Can be used at different abstraction levels.
Maximal level: just one bubble. Renement: renement of a bubble in separate specialized functions. The renement can be repeated up to a satisfactory level of detail.
D2 D3
D1 D4
A
D5
D1 D1
A1
D2 D2
A2
D5
Flow continuity constraint: the renement of a function must preserve the same input and output ows.
A3
D4 D3
42 / 81
Another DFD example
Specica di un sistema di monitoraggio di un paziente.

I segnali vitali del paziente (temperatura, pressione, polso) sono misurati periodicamente e convertiti in forma manipolabile da programma; essi vengono confrontati coi dati ammissibili per il paziente, memorizzati in forma permanente su di un le, formattati e memorizzati in un le storico. Se i dati del paziente sono al di fuori dei limiti prestabiliti viene generato un messaggio di allarme che richiama lattenzione del personale sanitario. Inoltre, un infermiere pu occasionalmente, cio in modo asincrono, richiedere un rapporto sulle condizioni del paziente: in questo caso il rapporto viene generato a partire dallarchivio storico.
43 / 81
Another DFD example (cont.)

Specica di un sistema di monitoraggio di un paziente: passo 1.
44 / 81

Specica di un sistema di monitoraggio di un paziente: passo 2.
45 / 81

Dettaglio della funzione monitoraggio centrale.
46 / 81
Criteria for writing DFD

DFD model the system at regimen: ignore description of initialization and error management. DFD dont model control: ignore description of control ow and the synchronization of sub-processes. Evidentiate in the diagram the inputs and outputs of the whole system. Assign explicative names to the ows and the processes. Verify the correctness and the completeness of the information ow. Verify the continuity constraint. Description of the functions in the bubbles:
informal (natural language), semi-formal (pseudo-languages/pseudo-code), formal (only for research prototypes of DFD).
DFD: summary
Pro: Easy to use. Understandable. General. Contra: No formal specication. Impossible to evaluate or execute the specication. Limitations: DFD dont describe control and synchronization. DFD dont model dynamic view (not at regime) of the system. A system cannot always be modeled as a function.
48 / 81
Example: event-oriented modeling

System modeled as reactive system.
System consists of states and transitions. Transitions describe reactions to events.
DISCONNECT
DETECT END OF CALL
CONNECT TO HANDSET
VOICE CALL
Models often more powerful than automata:

Hierarchical or with parallelism. Sometimes fully formal. Basis for, e.g. developing real-time systems.
WAIT FOR CALL ACKNOWLEDGE CONNECTION
DATA DETECT END OF CALL
DISCONNECT FROM COMPUTER
CONNECT TO COMPUTER
Functional requirements are not considered!

Sequence diagrams
Show the sequence of events that take place during some user interaction with a system. You read them from top to bottom to see the order of the actions that take place. Cash withdrawal from an ATM: Validate card. Handle request. Complete transaction.
50 / 81
Interface specication
Most systems must operate with other systems and the operating interfaces must be specied as part of the requirements. Three types of interface may have to be dened:
Procedural interfaces. Data structures that are exchanged. Data representations.
Formal notations are an effective technique for interface specication.
51 / 81
The requirements document
The requirements document is the ofcial statement of what is required of the system developers. Should include both a denition of user requirements and a specication of the system requirements. It is NOT a design document. As far as possible, it should set off (describe clearly) WHAT the system should do rather than HOW it should do it.
52 / 81
Users of a requirements document

System customers: specify the requirements and read them to check that they meet their needs. They specify changes to the requirements. Managers: use the requirements document to plan a bid for the system and to plan the system development process. System engineers: use the requirements to understand what system is to be developed. System test engineers: use the requirements to develop validation tests for the system. System maintenance engineers: use the requirements to help understand the system and the relationships between its parts.
53 / 81
Example: ANSI/IEEE-Standard STD-830-1984 (simplied)

Denes a generic structure for a requirements document that must be instantiated for each specic system. 1 Introduction.
1 2 3 4 5 2
Product objectives. Product scope. Denitions, acronyms, abbreviations. References. Overview of requirements description. Product function. User description. General restrictions. Acceptance criteria and dependencies.
General description.
1 2 3 4
3 4
Specic requirements. Appendix.

Requirements Analysis Ingegneria del SW, 11.03.11 54 / 81

http://standards.ieee.org/reading/ieee/std_public/ description/se/830-1993_desc.html
1
Introduction.
1 2 3 4 5
Objectives of the Requirements Document. Product objectives. Denitions, acronyms, abbreviations. References. Document structure. Product description (from the different points of view). Product functionalities. User characteristics. Constraints.
General description.
1 2 3 4
3 4 5
The requirements (functional, non-functional, user, system) Appendices. Index.

The standard IEEE 830-1993 is concerned with the Software Requirements Specication (SRS). It mandates that an SRS must satisfy 8 quality attributes:
1 2 3 4 5 6 7 8
Unambiguous. Correct. Complete. Veriable. Consistent. Modiable. Traceable. Ranked.
56 / 81
IEEE-Standard STD-830-1993: unambiguous
An SRS is unambiguous if and only if every requirement stated therein has only one interpretation. As a minimum, this requires that each characteristic of the nal product is described using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term must be included in a glossary where its meaning is made more specic. Ogni requisito ha una sola interpretazione possibile, sia per chi lo denisce (chi scrive), sia per chi lo usa (chi legge).
57 / 81
IEEE-Standard STD-830-1993: correct
An SRS is correct if and only if every requirement stated therein is one that the software shall meet. Ogni requisito rappresenta fedelmente nel sistema nale qualcosa che stato richiesto: Da questa denizione segue che:
Non pu esistere nessun tool o procedura che verica la correttezza no a quando il sistema non implementato. possibile vericare la correttezza delle speciche rispetto ad altre speciche, ad esempio pi astratte.
58 / 81
IEEE-Standard STD-830-1993: complete

An SRS is complete if it possesses the following qualities:
1
Inclusion of all signicant requirements, whether relating to functionality, perfomance, design constraints, attributes or external interfaces. Denition of the responses of the software to all reliable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to valid and invalid input values. Full labelling and referencing of all gures, tables, and diagrams in the SRS and denition of all terms and units of the measure.
Any SRS that uses the phrase TBD ... is not complete. If it is necessary, it should be accompanied by: A description of the conditions causing the TBD (for example, why an answer is not known) so that the situation can be solved. A description of what must be done to eliminate the TBD. Contiene i requisiti di tutte le funzionalit del sistema, e specica, per tutte le possibili classi di input, la risposta del sistema. La completezza spesso ottenibile solo incrementalmente, dopo rafnamenti successivi.
IEEE-Standard STD-830-1993: veriable
An SRS is veriable if and only if every requirement stated therein is veriable. A requirement is veriable if and only if there exists some nite cost-effective process with which a person or machine can check that the software product meets the requirement. If a method cannot be devised to determine whether the software meets a particular requirement then that requirement has to be removed or revised. Ogni requisito deve essere chiaro. Se un requisito non esprimibile in termini vericabili nel momento in cui lo SRS viene denito, dovrebbe essere denito un momento del ciclo di vita del software entro cui il requisito deve essere presentato in una forma vericabile.
60 / 81
IEEE-Standard STD-830-1993: consistent
Consistency refers to internal consistency. An SRS is consistent if and only if no set of individual requirements described in it conict. There are three types of likely conicts in an SRS: Two or more requirements might describe the same real world object but use different terms for that objects. The specied characteristics of the real world object might conict. There might be a logical or temporal conict between two specied actions.
61 / 81
IEEE-Standard STD-830-1993: modiable
An SRS is modiable if and only if its structure and style are such that any necessary changes to the requirements can be made easily, completely and consistently. Modiability generally requires an SRS to: Have a coerent and easy-to-use organization, with a table of contents, an index, and explicit cross-referencing. Not to be redundant. Whenever redundancy is necessary, the SRS should include explicit cross-references to make it modiable. Express each requirement separately, rather than intermixed with other requirements.
62 / 81
IEEE-Standard STD-830-1993: traceable

An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of the requirement in future development or enhancement of the documentation. Two types of traceability are recommented: Backward Traceability: depends upon each requirement explicitly referencing its source in previous documents. Forward Traceability: depends upon each requirement in the SRS having a unique name or reference number. Ogni requisito deve essere identicabile univocamente (FT). Quando un requisito A nello SRS deriva da un altro requisito B, deve essere specicata la dipendenza di A da B (BT).
63 / 81
IEEE-Standard STD-830-1993: ranked
An SRS is ranked for importance and/or stability if each requirement in it has an identier to indicate either the importance or stability of that particular requirement. Typically, all of the requirements that relate to a software product are not equally important. Some requirements may be essential, while others may be desiderable. Each requirement in the SRS should be identied to make these differences clear and explicit
64 / 81
NASA-Standard SMAP-DID-P200-SW (simplied)

1 2 3 4
Introduction. Related documentation. Requirements on external interfaces. Requirements specication.

1 2 3 4 5
Processes and data requirements. Behavior and quality requirements. Security requirements. Implementation constraints and installation requirements. Development goals.
5 6 7 8
Plan for incremental delivery of subsystems. Denitions, acronyms, abbreviations. Notes. Appendix.
V-Model-Standard: customer requirements (simplied)

1 2 3 4 5
General. Analysis of status quo (current situation). IT security goals. Threat and risk analysis. System requirements.
1 2 3 4 5
General system description and intended use. Organizational context for system deployment. Description of external interfaces. Functionality requirements. Quality requirements. Technical constraints. Organizational constraints. Miscellaneous constraints.
Constraints.
1 2 3
A concrete example of a simplied product sketch
Outline
67 / 81
Project sketch organization
Section I Problem description and goals. Section II Functionality. Section III User prole. Section IV Acceptance criteria. Section V Development, deployment, and maintenance environments, interfaces, and other considerations. Section VI General architecture (solution sketch). Section VII Information sources (e.g. contact persons, manuals, glossary).
68 / 81
Project sketch an example
Customer (bank manager or head of IT division) to IT consultant:

The entire account processing including cash payments, checks, and electronic transactions (e.g. transfers and e-banking) for our bank branch are currently supported by an antiquated accounting system. The support of our bank employees and, especially, our customer representatives is inadequate: information about customers must be individually extracted from individual accounts. Simple queries such as computing balances over multiple customer accounts cannot be carried out directly. We would like a new branch information system that extends the functionality of the current system and provides better support for the customer representatives and other bank employees. Moreover, we expect an improvement in overall productivity.
Typical: imprecisely dened improvement of the status quo.

Bank information system (BIS)

Delivered on . . . by . . .
Section I Problem description and goals. Section II Functionality. Section III User prole. Section IV Acceptance criteria. Section V Development, deployment, and maintenance environments, interfaces, and other considerations. Section VI General architecture (solution sketch). Section VII Information sources (e.g. contact persons, manuals, glossary).
70 / 81
BIS Project sketch Section I. Project description and goals
The information system should help administer data and accounts for customers of branch banks. Primary goals are:
Fast retrieval of up-to-date information about customers and their accounts, to aid customer support. Cost-effective and secure administration of payments. To automate the processing of standing orders.
The system should allow for a printer that prints account statement so that... Employee training is planned. Maximally 2 employees per branch...
71 / 81
BIS Project sketch Section II: Functionality
Develop a comprehensive Bank Information System (BIS) for the customers different branch banks. Functionality can be loosely categorized as follows:
(a) Account administration. The analysis of the current customer and account data indicates that the following functionality is required:
Create new accounts. Delete and change accounts. Create, change, and delete standing orders. ...
(b) Payments. Payments require the following functionality:...
72 / 81
BIS Project sketch Section III: User prole
Users of BIS are, exclusively, employees of the branch bank. They are:
Bank tellers who process cash payments. Customer representatives who use the information system to advise customers and administer their data. Administrators who maintain user data, x technical problems, and are responsible for backups.
73 / 81
BIS Project sketch Section IV: Acceptance criteria

The primary criteria are the execution time of the various functions and the correctness of account data and the automatic payment processing. The time for manual activities (payments, information processing, account administration) should be substantially reduced with respect to the current system. The automatic functions... As far as possible, all data should be administered in an object-oriented database management system. This is mandatory for customer and account data. The security of the data must be guaranteed using a mechanism for access control. Testing should be employed to verify all procedures that manipulate account data. Deposits, withdrawals, and transfers must function absolutely correctly.
BIS Project sketch Section V. Development, deployment, and maintenance environments, interfaces, and other considerations
Each branch should have its own software copy as well as a mainframe computer with multiple graphic terminals. The system operates in multi-user mode. The system should be linked to an external central system that coordinates the work of the individual branches and maintains central data. The development and maintenance environment consist of Unix workstations and the operating environment consists of a SUN-compute server running Unix and supporting an Oracle database system. The data transfer between the central system and the BIS is over Datex-P cables. ...Graphical interfaces in the current standard (e.g. OSF-Motif) will be used.
BIS Project sketch Section V. Development, deployment, and maintenance environments, interfaces, and other considerations (cont.)
The system includes a one year guarantee. A maintenance contract can later be arranged. Subsequent system extensions possibly include a subsystem to aid investment planning and support for managing life-insurance policies.
76 / 81
BIS Project sketch Section VI. General architecture (solution sketch)

The system is based on a Client-Server-Architecture within a local-area network. All static customer and account data are maintained in a relational database on the server side. ... Cash transactions (deposits/withdrawals), for branch accounts, are carried out within the BIS. Non-cash transactions (e.g. checks, transfers, etc.), are rst processed by the BIS using a special transfer-account. From this special account... Section VII. Information sources (e.g. contact persons, manuals, glossary)...
Requirements validation
Goal: check whether the sketch is: Valid: Is the right functionality specied? For whom? Consistency: There should be no conicts between requirements. Completeness: The entire functionality should be specied. Realistic: It must be possible to implement the system under the given resource (time and nancial) constraints. How? Different approaches with different advantages/disadvantages:
Walk-through and requirements review. Construction of a prototype. Use of logic-based tools.
Process models sometimes prescribe form of analysis.
78 / 81
Conclusions
Outline
79 / 81
Conclusions
Key points
Requirements set out what the system should do and dene constraints on its operation and implementation. Functional requirements set out services the system should provide. Non-functional requirements constrain the system being developed or the development process. User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams. System requirements are intended to communicate the functions that the system should provide. A software requirements document is an agreed statement of the system requirements. The IEEE standard is a useful starting point for dening more detailed specic requirements standards.
Conclusions
Homework: a project
Development of a scheduling Class Scheduling System CSS for an educational institution, e.g. the Department of Computer Science of the University of Verona.
1
Assume the role of the client (or customer, i.e. the university), and write a problem (project) description. Among others, the description should address the following issues: Who will use the system? Who will/should administer the system? Which functionalities (input, output) should the system have? In which computer environment should the system work? Who could act as an expert, i.e. who is available to provide further information (and answer possible questions of the contractor about the project to be developed)? Which acceptance criteria (which kind of tests) should the system satisfy?
Assume the role of the contractor (i.e. provider, or system architect ) and, on the basis of the problem description, start the Analysis&Denition phase by giving a detailed analysis of the requirements and by writing a detailed and structured product (project) sketch.

Requirements Analysis: Luca Viganò

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Requirements Analysis: Luca Viganò

Hochgeladen von

Copyright:

Verfügbare Formate

Requirements Analysis

Ingegneria del SW, 11.03.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

See: Ian Sommerville. Software Engineering. Pearson Education Ltd.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

What system should your future IT-department design?

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

Well, there is some data to administer

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

And dont forget

Planning programs (time and cost plans). Support for E-commerce:

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

The analysis and denition phase

The analysis and denition phase

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

Functional, non-functional, and domain requirements

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

Types of non-functional requirements

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

Goals and requirements

Veriable non-functional requirement:

The analysis and denition phase

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

The analysis and denition phase

The analysis and denition phase

Types of requirement more in detail: User requirements

The analysis and denition phase

Types of requirement more in detail: System requirements

Luca Vigan (Universit di Verona)

Ingegneria del SW, 11.03.11

Luca Vigan (Universit di Verona)