Lec 20

(3) Software Requirements Specification (SRS) ™ Also called (Design Specification) ™ An abstract description of the S/W, which is basis for its design and implementation. There should be a clear and direct relationship between this document and the requirement specification, but the reader of this are S/W designers. ™

Such a specification is included mostly as part of system contract and is the basis for designing system acceptance tests.

™

Inputs, Process, Output, pre-conditions, post-conditions are the minimum required.

Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

35

SRS (2) Structured Language Specification ♦

Natural Language is required because of understandability.

♦

Many notations have been developed which rely on natural language in a controlled way using standard form and may use control constructs, (derived from program languages) and also use graphical highlighting.

♦

The form structure will vary depending on the requirement structuring technique (functional, data, object e.t.c).

♦

Functional oriented Specifications are most common.

Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

36

♦

Form based approach fits well with formal mathematical specification. A formal specification can be defined and paraphrased in a set of forms or a formal specification can be defined from the structured forms and used to refine the requirement specification.

♦

Other approaches (e.g. formal mathematical) tackle some problems of specifications ambiguity but at the cost of perhaps, readability.

Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

37

♦

SRS (3) ATM example of structured requirement specification (functional approach)

Function: Check-Card-Validity Description: Must ensure the card input by the user, is in date, contains account information e.t.c. Inputs: Bank-identifiers, account No. , Expiry date Source: Input read from card magnetic strip Output: Card-Status (OK, invalid) Destination: AutoTeller (Status passed to other parts of S/W) Requires: Bank list, account format, today’ date. Pre-condition: Card has been input and strip data read. Post-Condition: Bank-identifier is in bank list and account number matches Account format, expiry-date, today-date and card-status = OK Side effects: None Exercise: Design a format for object oriented specification technique

♦ ♦

A form based approach could obviously be automated. Pre and post conditions are used to specify the actions of the function.

♦ It is not an operational specification of what the function must do. ♦ The names used (in the form) must be defined elsewhere or if possible in data dictionary.

Document Structure and Standards Several recommended guides and standards exist to help define the structure of requirements documentation. These include IEEE P1233/D3 guide, IEEE Std. 1233 guide, IEEE Std. 830-1998, ISO/IEC 12119-1994. IEEE Std 1362-1998 concept of operations (ConOPs).

Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

39

Software Requirements Engg Requirements Engineering Process

Χ

Process Models

Requireme nts Elicitation

Χ

Process Actors Process Support and Manageme nt

Requireme nt Sources

Χ

Elicitation Techniques

Process Quality and

Improvemen t

Dr. Arshad A Shahid

Requireme nts Analysis Requireme nt Classificati on

Χ Χ Χ

Conceptual Modeling

Architectura l Design and Requiremen ts Allocation

Χ

Requireme nt Negotiation

Requireme nts Specificatio n

9

Χ

Requireme nt Definition Document

Χ Χ Χ

FAST-NU Islamabad

Software Requirements Specification (SRS)

Structure and Standards

Requireme nts Validation

Requireme nts Manageme nt

Conduct of Requireme nts Reviews

Change Management

Prototyping Model Validation

Requireme nts Attributes Requireme nts Tracing

Acceptance Tests

Document Quality

Spring 2009

40

Requirements Validation „ One or more formally scheduled points in the

requirements engineering process where the requirements are validated. „ Concerned with the process of examining the requirements document to ensure that it defines the right system (i.e., the system that the user expects).

Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

41

Requirements Validation (2) (1) The Conduct of Requirements Reviews Common means of validation is by inspection or formal reviews of the requirements document (s). (2) Prototyping validating the req. engineer’s interpretation of the system requirements, as well as for eliciting new requirements. (3) Model Validation Quality of the models developed during analysis should be validated. (4) Acceptance Test „ Essential property of a requirement is that it should be possible to validate that the finished product satisfies the requirement. „ Identifying and designing acceptance test may be difficult for non-functional requirements. To be validated, they must first be analysed to the point where they can be expressed quantitatively. Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

42

Requirements Validation (3) There are seven criteria in the validation process: 1. Correctness 2. Consistency - no conflicting/ambiguous requirements 3. Completeness - describes all possible situations 4. Realistic - Requirements of the user environment and practical 5. Needed - does each requirement describe something needed by the customer 6. Verifiable - can tests be written to demonstrate meeting the requirement 7. Traceable - trace requirement to system function Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

43

Requirements Management An activity that spans the whole software life cycle. Fundamentally about change management and the maintenance of the requirements. (1) Change Management Procedures that need to be in place and the analysis that should be applied to proposed changes. Strong links to the configuration management. (2) Requirements Tracing ¾ Tracing is fundamental to performing impact analysis when requirements change. ¾ A requirement should be traceable backwards to the requirements and stakeholders that motivated it. ¾ Conversely, a requirement should be traceable forwards into SRS and design entities that satisfy it (And into the code module that implement it). ¾ Requirements trace for a typical project will form a complex directed acyclic graph (DAG) of requirements. Modern requirements management tools have improved this situation and the importance of tracing (and requirements management in general) is starting to make an impact in software quality. Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

44

Software Requirements Engg Requirements Engineering Process

Χ

Process Models

Requireme nts Elicitation

Χ

Process Actors Process Support and Manageme nt

Requireme nt Sources

Χ

Elicitation Techniques

Process Quality and

Improvemen t

Dr. Arshad A Shahid

Requireme nts Analysis Requireme nt Classificati on

Χ Χ Χ

Conceptual Modeling

Architectura l Design and Requiremen ts Allocation

Χ

Requireme nt Negotiation

Requireme nts Specificatio n

Χ

Requireme nt Definition Document

Χ Χ Χ

FAST-NU Islamabad

Software Requirements Specification (SRS)

Structure and Standards

Document Quality

Requireme nts Validation

Χ Χ Χ Χ

Spring 2009

Conduct of Requireme nts Reviews

Prototyping Model Validation

Requireme nts Manageme nt

Χ

Change Management

Requireme nts Attributes

Χ

Requireme nts Tracing

Acceptance Tests

45

Requirement Engineering Roadmap „ Three radical ideas „ Modeling and analysis cannot be performed adequately in isolation from the organizational and social context in which the new system will have to operate „ RE should not focus on specifying the functionality of a new system, but instead should concentrate on modeling indicative and operative properties of the environment „ Attempt to build consistent and complete requirement models is futile. Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

46

What's the Future ? „ New techniques for formally modeling and analyzing „ „ „ „ „

properties of the environment Richer model for capturing and analyzing nonfunctional requirements Bridging the gap between requirements elicitation approaches. Better understanding of software architectural choices Reuse of requirement models Multidisciplinary training of requirements practitioners

Dr. Arshad A Shahid

FAST-NU Islamabad

Spring 2009

47