TME2093 Domain and Requirements Analysis Session 2

Semester 2, Sesi 2012/2013

Norazian Mohd Hamdan

Todays topics
Overview of Requirements Engineering Importance of Effective Requirements Analysis Introduction to Requirements Analysis Software Requirements Requirements Document

Requirements Engineering
The process of finding out, analysing, documenting and checking services provided by the system and its operational constraints is called requirements engineering (RE).

Requirements Engineering Processes

The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements However, there are a number of generic activities common to all processes
Requirements elicitation Requirements analysis Requirements validation Requirements management
4

Some of Requirements Engineering Activities

Elicitation
determining what the customer requires

Analysis & negotiation

understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result

Requirements specification
Document the requirements
5

Requirements Engineering Activities (cont)

System Modeling
building a representation of requirements that can be assessed for correctness, completeness, and consistency.

Validation
Reviewing/check the model that the requirement suit its intended purposes.

Management
identify, control and track requirements and the changes that will be made to them.
6

The requirements engineering process

Feasibility study Requirements elicitation and analysis

Requir ements specification Requirements validation

Feasibility report System models User and system requirements

Requirements document

Todays topics
Overview of Requirements Engineering Importance of Effective Requirements Analysis Introduction to Requirements Analysis Software Requirements Requirements Document

SDLC
Requirements analysis is the first activity in software development Important to make sure it is done correctly and within the development constraints

Software Projects Distribution

Resolution Type 1, or project success: The project is completed on-time and onbudget, with all features and functions as initially specified. Resolution Type 3, or project impaired: The project is cancelled at some point during the development cycle.

Resolution Type 2, or project challenged: The project is completed and operational but overbudget, over the time estimate, and offers fewer features and functions than originally specified.
10

SOURCE(06/2003): http://www.standishgroup.com/sample_research/chaos_1994_2.php

Project Success Factors

1. User Involvement 2. Executive Management Support 3. Clear Statement of Requirements 4. Proper Planning 5. Realistic Expectations

% of Responses
15.9% 13.9% 13.0% 9.6% 8.2%

6. Smaller Project Milestones

7. Competent Staff 8. Ownership 9. Clear Vision & Objectives 10. Hard-Working, Focused Staff Other

7.7%
7.2% 5.3% 2.9% 2.4% 13.9%

SOURCE(06/2003): http://www.standishgroup.com/sample_research/chaos_1994_1.php
11

Project Challenged Factors

1. Lack of User Input 2. Incomplete Requirements & Specifications 3. Changing Requirements & Specifications

% of Responses
12.8% 12.3% 11.8%

4. Lack of Executive Support

5. Technology Incompetence 6. Lack of Resources 7. Unrealistic Expectations 8. Unclear Objectives 9. Unrealistic Time Frames 10. New Technology

7.5%
7.0% 6.4% 5.9% 5.3% 4.3% 3.7%

Other

23.0%
SOURCE(06/2003): http://www.standishgroup.com/sample_research/chaos_1994_2.php
12

Project Impaired Factors

1. Incomplete Requirements 2. Lack of User Involvement 3. Lack of Resources 4. Unrealistic Expectations

% of Responses
13.1% 12.4% 10.6% 9.9%

5. Lack of Executive Support

6. Changing Requirements & Specifications 7. Lack of Planning 8. Didn't Need It Any Longer 9. Lack of IT Management 10. Technology Illiteracy Other

9.3%
8.7% 8.1% 7.5% 6.2% 4.3% 9.9%

SOURCE(06/2003): http://www.standishgroup.com/sample_research/chaos_1994_2.php
13

SUCCESS CRITERIA
1. User Involvement 2. Executive Management Support 3. Clear Statement of Requirements 4. Proper Planning 5. Realistic Expectations

POINTS
19 16 15 11 10

6. Smaller Project Milestones

7. Competent Staff 8. Ownership 9. Clear Vision & Objectives 10. Hard-Working, Focused Staff TOTAL

9
8 6 3 3 100

SOURCE(06/2003): http://www.standishgroup.com/sample_research/chaos_1994_2.php
14

The Facts of Requirements Error

The later the error is detected, the more expensive it will be to fix it. Many unknown error until certain stage in development life cycle. Many requirements errors being made. Requirements errors sometimes cannot be avoided. Requirements errors can be detected. Requirements errors can be reduced.
15

Common Requirements Error

Incorrect facts Omissions or incomplete Inconsistent Ambiguity Unrealistic Not verifiable Gold plating look nice from outside but number of hidden/inside errors Not traceable
16

Potential Impacts of Requirements Error

Software/Product dont reflect the real needs of the customer. Unsatisfied end-users and customers. Disagreement between customers and developers, wasting time and resources. Impossible to thoroughly test that the software meets its intended requirements. Both time and money wasted building the wrong system.
17

More on Potential Impacts of Requirements Error

Expensive maintenance Expensive to be changed Out of schedule Late delivery

18

Cost of Fixing An Requirement Error

$1 During the requirements definition phase

$5 During design phase

$10 During coding phase $20 During unit testing phase $200 After Delivery

19

Benefits of Requirements Analysis

Understanding of agreement. Basis for contracts. Rapport building between developers and customers. Project artifact. Source of reference design, testing and maintenance. For validation. Easing project management.
20

Todays topics
Overview of Requirement Engineering Importance of Effective Requirements Analysis Introduction to Requirements Analysis Software Requirements Requirements Document

21

Feasibility studies
A feasibility study decides whether or not the proposed system is worthwhile. A short focused study that checks
If the system contributes to organisational objectives. If the system can be engineered using current technology and within budget. If the system can be integrated with other systems that are used.
22

Feasibility Study Implementation

Based on information assessment (what is required), information collection and report writing. Questions for people in the organisation
What if the system wasnt implemented? What are current process problems? How will the proposed system help? What will be the integration problems? Is new technology needed? What skills? What facilities must be supported by the proposed system?
23

Requirements Elicitation
Not as simple as:
Define system objectives. What is to be accomplished. System and business integration. How it will be used.

24

Requirements Elicitation Problems

Scope problem
unnecessary technical details.

Problem of Volatility
Changing requirements.

Problem of understanding
Customers are unsure of what is needed.

25

Sources of Possible Requirements

Analysis & Negotiation

Each requirements is consistent with the overall objective. Requirements are specified at appropriate level of abstraction. The requirements is really necessary. Each requirements is bounded and unambiguous Each requirement is attributed (eg: source, description, etc). No conflicting requirements. Each requirement is realistic. Each requirement is testable, once implemented.
27

Requirements Analysis Problems

Communication intensive
Misinterpretation. Omission. Misunderstanding. Etc.

Requirements conflict. Complexity. Poor communication. Inadequate techniques. Tend to make short-cut; etc.
28

Homework
Based on your assignment 1s title, do a brief feasibility study on the system.

29/04/2013

29 Domain and Requirements Analysis

Todays topics
Overview of Requirements Engineering Importance of Effective Requirements Analysis Introduction to Requirements Analysis Software Requirements Requirements Document

30

What are Requirements?

Statements of a system services or constraints. What an application is meant to do; NOT HOW. Descriptions and specifications of a system. Something required; something wanted or needed A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification or other formally imposed document IEEE. Features of a system or description of something the system is capable of doing to fulfill the systems purpose.

31

More on Requirements
It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. 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.
32

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 system services. Written as a contract between client and contractor.

Software specification
A detailed software description which can serve as a basis for a design or implementation. Written for developers.
33

User requirements
Should describe functional and non-functional requirements so that they are understandable by system users who dont have detailed technical knowledge. User requirements are defined using natural language, tables and diagrams. Problems with natural language?

29/04/2013

Domain and Requirements Analysis

34

System requirements
More detailed specifications of user requirements. Serve as a basis for designing the system. May be used as part of the system contract. System requirements may be expressed using system models.

29/04/2013

Domain and Requirements Analysis

35

Definitions and specifications

Requirements definition 1. The software must provide a means of repr esenting and 1. accessing external files created by other tools. Requirements specification 1.1 The user should be provided with facilities to define the type of 1.2 external files. 1.2 Each external file type may have an associated tool which may be 1.2 applied to the file. 1.3 Each external file type may be represented as a specific icon on 1.2 the users display. 1.4 Facilities should be provided for the icon repr esenting an 1.2 external file type to be defined by the user. 1.5 When a user selects an icon repr esenting an external file, the 1.2 effect of that selection is to apply the tool associated with the type of 1.2 the external file to the file represented by the selected icon.
36

Requirements readers
User requirements Client managers System end-users Client engineers Contractor managers System architects System end-users Client engineers System architects Software developers Client engineers (perhaps) System architects Software developers
37

System requirements

Software design specification

Functional and non-functional 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 reflect characteristics of that domain.
38

Todays topics
Overview of Requirement Engineering Importance of Effective Requirements Analysis Introduction to Requirements Analysis Software Requirements Requirements Document

39

Requirements Document
An official statement of the system requirements for customers, end-users, stakeholders and software developers. Different names such as functional specification, the requirements definition, the software requirements specification (SRS), the safety/reliability plan. Documents containing a complete description of what the software will do without describing how it will do it.
40

More of Requirements Document

The requirements document is the official statement of what is required of the system developers. Provides a black-box description of what the system should do (input, output & their relationship). Communicating to two audiences customer & technical community. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.
41

Why Requirements Must Be Written?

To clearly define project goals. For inspecting work in progress or completed properly. For a proper testing. Track productivity. For predicting the project size and effort of its next job. To satisfy the customers.
42

Organizing Requirements
Best organized into conceptual categories. Analyst should not divert into implementation approach while organizing the requirements. Stated in operational and logistical terms, issues such as.
Operational capabilities; Physical characteristics; Performance parameters; Expected values; Interfaces and interactions with its environment; Documentation requirements; reliability requirements; logistical requirements and personnel requirements.
43

Benefit of structured requirements

Identify derived requirements. Organize requirements into their appropriate level of detail. Verify the completeness of the set of requirements. Identify inconsistencies among requirements. Clearly identify the capabilities, conditions, and constraints for each requirements. Develop common understanding with the customer of the purpose and objectives. Identify requirements that will complete the SRS.
44

Benefits of Good SRS

Establish the basis for agreement between the customers and the suppliers on what the software product is to do. Reduce the development effort. Provide a basis for estimating costs and schedules. Provide a baseline for validation and verification. Facilitate transfer. Serve as a basis for enhancement.
45

Guidelines for Preparing a Good SRS

1. 2. 3. 4. 5. 6. 7. 8. Nature of the SRS. Environment of the SRS. Characteristics of a good SRS. Joint preparation of the SRS. SRS evolution. Prototyping. Embedding design in the SRS. Embedding project requirements in the SRS.
46

1. Nature of the SRS

Functionality - What the software is supposed to do? External interfaces - How does the software interact with people, the systems hardware, other hardware, & other software. Performance - What is the speed, availability, response time, recovery time, etc of various software functions. Attributes considerations for portability, correctness, maintainability, security, reliability, etc ? Design constraints imposed on an implementation any required standards in effect, implementation language, policies for database integrity, resource limits, operating environments(s), etc?
47

2. Environment of the SRS

Should correctly define all of the software requirements. Should not describe any design or implementation details. Should not impose additional constraints on the software.

48

3. Characteristics of a good SRS

Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable
49

Correct
An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet compared with any applicable superior specification, such as a system requirements specification, with other project documentation, and with other applicable standards, to ensure that it agrees customer or user can determine if the SRS correctly reflects the actual needs
50

Unambiguous
An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation Problems with NL specification
Ambiguity Over-flexibility Lack of modularisation

Alternatives to NL specification
Form-based specifications Procedure Description Language-based requirements definition Representation Tools diagrams and models (OO models @ DFD)
51

Complete
An SRS is complete if, and only if, it includes the following elements:
All significant requirements Definition of the responses to all input data Full labels and references to all figures, tables, and diagrams

Use of TBDs (

to be done

) should be accompanied by

A description of the conditions causing the TBD A description of what must be done to eliminate the TBD (who and when)
52

Consistent
Consistency refers to internal consistency
No requirements conflict

Three Types Conflicts in an SRS

Real-world objects conflict Logical or temporal conflict between two specified actions Different terms are used for same object

If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct
53

Ranked for importance and/or stability

Not all requirements that relate to a software product are equally important Each requirement should be ranked Three Categories of Requirements necessity
Requirements that absolutely must be met Requirements that are highly desirable but not necessary Requirements that are possible but could be eliminated

Stability relates to the likeliness of the requirement will be changed

54

Verifiable
For each requirements, the software product can be checked whether or not it meets the requirement Requirement statements use concrete terms and measurable quantities

55

Modifiable
changes to the requirements can be made easily, completely, and consistently while retaining the structure and style of the SRS SRS should be
coherent (logically related) and easy-to-use organization. Not be redundant. Express each requirement separately.
56

Traceable
The origin of each of its requirements is clear Two types of traceability:
Backward traceability - explicitly referencing its source Forward traceability - unique name or reference number

57

4. Joint Preparation of the SRS

SRS should be jointly prepared by the supplier and customer Customers usually do not understand the software development process Suppliers usually do not understand the customer s problem

58

5. SRS Evolution
SRS may need to evolve as the development of the software product progresses Additional changes may ensue as deficiencies, shortcomings, and inaccuracies are discovered in the SRS Two major considerations
Requirements should be specified as completely and thoroughly as is known at the time. The fact that they are incomplete should be noted. A formal change process should be initiated
59

6. Prototyping
Provides quick feedback Displays unanticipated aspects Less change during development

60

7. Embedding Design in The SRS

distinguish between identifying required design constraints and projecting a specific design Design items NOT to be included
Partitioning the software into modules Allocating functions to the modules; Describing the flow of information or control between modules Choosing data structures

In special cases some requirements may severely restrict the design eg: security @ safety systems
61

 The SRS should address the software product, not the process of producing the software product. Matters pertaining to production of software and thus should not be included in the SRS, such as:
Cost Delivery schedules Reporting procedures Software development methods Quality assurance Validation and verification criteria Acceptance procedures

8. Embedding Project Requirements in The SRS

62

Requirements Specification
Could be
a written documents a graphical model formal mathematical model usage scenarios prototypes or their combination
more consistent

May use a standard template

Some prefer flexibility

combination of text and graphics (especially for large system)

Domain and Requirements Analysis
63

29/04/2013

Software Requirements Specification

IEEE requirements standard

Table of Contents 1. Introduction
1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview

2. Overall description
2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies

3. Specific requirements 4. Appendixes 5. Index

Software Requirements Specification

IEEE standard too general. Possible structure of organizational requirement document based on IEEE standard structure as:
Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index
65

How Details requirements document?

How much detail should be provided depends on:
The size of the system The need to interface to other systems The readership The stage in requirements gathering The level of experience with the domain and the technology The cost that would be incurred if the requirements were faulty
66

Some of SRS Quality

Unambiguous Complete Correct Understandable Verifiable Internally Consistent Externally Consistent Achievable Concise
67

More of SRS Quality

Design Independent Traceable Modifiable Electronically Stored Executable/Interpretable Annotated by relative importance Annotated by relative stability Annotated by Version Not Redundant
68

More of SRS Quality

At right level of detail Precise Reusable Traced Organized Cross-referenced

69