Req. Engg. Spec. Analysis. Model.

Requirements Engineering & Analysis, Specification, Modeling Fall 2009 SEN-261 : Software Engineering Tazeen Muzammil

Introduction to Requirements Definition “A feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose”

Strengths 1) Must/Shall

2) Should

3) Will

Goal: To understand the problem in terms of the following:

- Organization - Existing Systems - Processes - Improvements Requirement Engineering, Analysis, Specification & Modeling

2

Requirements Engineering REQUIREMENTS ELICITATION AND ANALYSIS

Problem analysis

Problem description

Have we captured Are we using the right all the user need? techniques or views?

Prototyping and testing

Is this function feasible?

Requirement Engineering, Analysis, Specification & Modeling

REQUIREMENTS DEFINITION AND SPECIFICATION

Documentation and validation

Have we captured what the user expects?

3

User Requirements Definition 1.LIBSYS shall keep track of data

required by copyright licensing agencies in the UK and elsewhere.

Requirement Engineering, Analysis, Specification & Modeling

4

System Requirements Specification 1.1. On making a request for a document from LIBSYS, the requestor shall be presented with a form that records details of the user and the request made’ 1.2. LIBSYS request form shall be stored on the system for five years from the date of the request. 1.3. All LIBSYS request forms must be indexed by user, by the name of the material and by the supplier of the request. 1.4. LIBSYS shall maintain a log of all requests that have been made to the system. 1.5. For material where authors lending rights apply loan details shall be sent monthly to copyright licensing agencies that have registered with LIBSYS.

Requirement Engineering, Analysis, Specification & Modeling

5

Functional and nonfunctional 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

Requirement Engineering, Analysis, Specification & Modeling

6

Non-functional requirements Define 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 specified 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

Requirement Engineering, Analysis, Specification & Modeling

7

Classification of Nonfunctional Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational 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. Requirement Engineering, Analysis, Specification & Modeling

8

Classification of Nonfunctional Non-functional requirements

Product requirements

Efficiency requirements

Reliability requirements

Usability requirements

Performance requirements

Organizational requirements

Portability requirements

Delivery requirements

Space requirements

External requirements

Interoperability requirements

Implementation requirements

Requirement Engineering, Analysis, Specification & Modeling

Ethical requirements

Standards requirements

Legislative requirements

Privacy requirements

Safety requirements

9

Non-functional requirements Examples: • Product Requirements 8.1. The user interface for LIBSYS shall be implemented as simple HTML without frames or JAVA applets. • Organizational Requirements 9.3.2. The system development process and deliverable document shall conform to the process and deliverables defined in XYZ-CO-SP-STAN-95. • External Requirements 10.6. The system shall not disclose any personal information about system users apart from their name and library reference number to the library staff who use the system.

Requirement Engineering, Analysis, Specification & Modeling

10

Functional requirements 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

Requirement Engineering, Analysis, Specification & Modeling

11

Functional requirements Examples: 1. The user shall be able to search either all the initial set

of databases or select a subset from it. 2. The system shall provide appropriate viewers for the user to red document in the document store. 3. Every order shall be allocated a unique identifier(ORDERID) which the user shall be able to copy to the accounts permanent storage area.

Requirement Engineering, Analysis, Specification & Modeling

12

Classification of Functional Requirements User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers Should describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers

Requirement Engineering, Analysis, Specification & Modeling

13

Classification of Functional Requirements System requirements A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor 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.

Requirement Engineering, Analysis, Specification & Modeling

14

Classification of Functional Requirements

Requirement Engineering, Analysis, Specification & Modeling

15

Requirement Engineering Steps 1. 2. 3. 4. 5. 6.

Requirement Elicitation Requirement Analysis Requirement Specification System Modeling Requirement Validation Requirement Management

Requirement Engineering, Analysis, Specification & Modeling

16

Requirements Elicitation Requirements elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering. Requirement Engineering, Analysis, Specification & Modeling

17

Requirements Elicitation Types Requirements Elicitation Techniques: 1.

Application Specification Techniques

Interview, Group Meeting 1.

Quality Function Deployment

Survey, S/W review, Interview 1.

Use Case

Interview, Observation Requirement Engineering, Analysis, Specification & Modeling

18

Requirements Elicitation Techniques Interview / Meeting Survey / Questionnaire Braining Storming and idea reduction Review Internal / External Documents Review Software Observation Business Plan Requirement Engineering, Analysis, Specification & Modeling

19

Requirements Analysis Goal

To bridge the gap between the problem domain and the technical domain Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. Requirements analysis involves frequent communication with system users to determine specific feature expectations, resolution of conflict or ambiguity in requirements as demanded by the various users or groups of users, avoidance of feature creep and documentation of all aspects of the project development process from start to finish. Requirements analysis is a team effort that demands a combination of hardware, software and human factors engineering expertise as well as skills in dealing with people.

Requirement Engineering, Analysis, Specification & Modeling

20

Requirements Analysis Tasks Problem Recognition Evaluation and Synthesis Modeling Specification Review

Requirement Engineering, Analysis, Specification & Modeling

21

Requirements Specification Goal To provide a representation of the software for the customer’s review and approval Software requirements document (or SRS) is the official statement of what the system developers should implement. It should include both the user requirements for a system and a detail specification of the system requirements. 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

Requirement Engineering, Analysis, Specification & Modeling

22

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

Requirement Engineering, Analysis, Specification & Modeling

23

S/W Requirement Specification (SRS) Introduction Functional Requirements Definition Non-functional Requirements Definition System Model Information Description Functional Description Behavioral Description

Validation Criteria Bibliography Appendix & Glossary Requirement Engineering, Analysis, Specification & Modeling

24

Requirements Validation Goal Requirements validation examines the specification to ensure that the system requirements have been stated unambiguously; that inconsistencies, omissions and errors have been detected and corrected.

Requirement Engineering, Analysis, Specification & Modeling

25

Requirements Review The primary requirements validation technique is review: Conducted by both software developer and customer Once review is completed, SRS is signed off by both the parties. After approval the specification becomes a ‘Contract’ for software development Requirement Engineering, Analysis, Specification & Modeling

26

Requirements Review? Are the requirements complete? Are the requirements concise? Are the requirements correct? Are the requirements consistent? Are the requirements modular? Can they accommodate change? Are the requirements realistic? Is the requirement needed by the customer? Are the requirements traceable?

Requirement Engineering, Analysis, Specification & Modeling

27

Requirements Management Goal Requirements management is a set of activities that help the project team to identify, control, and track requirements and changes to requirements at any time as the project proceeds.

Requirement Engineering, Analysis, Specification & Modeling

28

Analysis Methods & Models Analysis Method: Structured Analysis Object-Oriented Analysis

Modeling Techniques: Data Modeling (Entity Relation Diagram) Processing/Function Modeling (Data Flow Diagram) Control/Behavior Modeling (State Transition Diagram)

Requirement Engineering, Analysis, Specification & Modeling

29

Structured Analysis

Requirement Engineering, Analysis, Specification & Modeling

30

Object-Oriented Analysis

Requirement Engineering, Analysis, Specification & Modeling

31

Requirements Analysis: Structured Techniques

Requirement Engineering, Analysis, Specification & Modeling

32

Data Modeling - ERD Data objects, attributes and relationships Cardinality and Modality (Crow Foot Notation) Entity Relationship diagram (ERD)

Entity

Doctor

Relationship

Treats

Requirement Engineering, Analysis, Specification & Modeling

Entity

Patient

33

Data Flow Diagrams Graphical representation that depicts information flow and the transforms that are applied as data moves from input to output Concepts: Context Diagram / Level 0 Diagram Leveling Balancing Process Specification Requirement Engineering, Analysis, Specification & Modeling

34

DFD symbols External Entity

Process

Data Item Data Store

Producer/Consumer of information outside the bounds of the system Transformer of information Data item or collection of data items Repository of data stored for one or more processes Requirement Engineering, Analysis, Specification & Modeling

35

State Transition Diagrams State

Represent states of the system

Transitions between states; activities that trigger state change Requirement Engineering, Analysis, Specification & Modeling

36

Requirements Analysis:  Object-Oriented Techniques

Requirement Engineering, Analysis, Specification & Modeling

37

Object Model ClassName

Basic class model includes name, attributes, & operations

Attribute 1 Attribute 2 Attribute N Operation 1 Operation N

Superclass discriminator

Subclass1

Inheritance

Subclass2

Requirement Engineering, Analysis, Specification & Modeling

38

Object Model AssemblyClass

Part1-Class

1..*

Aggregation

Part2-Class

Class

Exactly one

Class

Many/Optional

Class

One or more

Multiplicity of Associations

Requirement Engineering, Analysis, Specification & Modeling

39

Object Modeling Steps Identify objects and classes Prepare a data dictionary Identify associations between objects Identify attributes of objects and links Organize and simplify object classes using inheritance Verify that access paths exist for likely queries Iterate and refine the model Group classes into modules

Requirement Engineering, Analysis, Specification & Modeling

40