Req. Engg. Spec. Analysis. Model

Requirements Engineering &

Analysis, Specification, Modeling

Fall 2009SEN-261 : Software Engineering

Tazeen Muzammil

Requirement Engineering, Analysis, Specification & Modeling 2

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”

Strengths1) Must/Shall 2) Should 3) Will

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

- Organization - Existing Systems- Processes - Improvements


Requirements Engineering

Problemanalysis

Problemdescription

Prototypingand testing

Documentationand

validation

Have we capturedall the user need?

Are we usingthe right

techniques orviews?

Is this functionfeasible?

Have we capturedwhat the user

expects?

REQUIREMENTS ELICITATIONAND ANALYSIS

REQUIREMENTSDEFINITION

AND SPECIFICATION

User Requirements Definition

1.LIBSYS shall keep track of data required by copyright licensing agencies in the UK and elsewhere.


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.


Functional and non-functional requirements

Functional requirementsStatements 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 requirementsConstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain


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 methodNon-functional requirements may be more critical than functional requirements. If these are not met, the system is useless


Classification of Non-functional

Product requirementsRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

Organisational requirementsRequirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.

External requirementsRequirements 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 Non-functional


Performancerequirements

Spacerequirements

Usabilityrequirements

Ef ficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

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.


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


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(ORDER-ID) which the user shall be able to copy to the accounts permanent storage area.


Classification of Functional Requirements

User requirementsStatements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customersShould describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge

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



System requirementsA structured document setting out detailed descriptions of the system services. Written as a contract between client and contractorMore detailed specifications of user requirementsServe as a basis for designing the systemMay be used as part of the system contractSystem requirements may be expressed using system models.





Requirement Engineering Steps

1. Requirement Elicitation2. Requirement Analysis 3. Requirement Specification4. System Modeling5. Requirement Validation6. Requirement Management

Requirements ElicitationRequirements 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.


Requirements ElicitationTypes Requirements Elicitation Techniques:1. Application Specification Techniques

Interview, Group Meeting

2. Quality Function DeploymentSurvey, S/W review, Interview

3. Use Case Interview, Observation



Requirements Elicitation

TechniquesInterview / MeetingSurvey / QuestionnaireBraining Storming and idea reductionReview Internal / External DocumentsReview Software ObservationBusiness Plan

Requirements AnalysisGoal

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.


Requirements AnalysisTasks

Problem RecognitionEvaluation and SynthesisModelingSpecificationReview



Requirements Specification

GoalTo 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

Users of a Requirements Document


Use the requirements todevelop validation tests forthe system

Use the requirementsdocument to plan a bid forthe system and to plan thesystem development process

Use the requirements tounderstand what system is tobe developed

System testengineers

Managers

System engineers

Specify the requirements andread them to check that theymeet their needs. Theyspecify changes to therequirements

System customers

Use the requirements to helpunderstand the system andthe relationships between itsparts

Systemmaintenance

engineers


S/W Requirement Specification

(SRS) IntroductionFunctional Requirements Definition Non-functional Requirements Definition System Model

Information Description Functional Description Behavioral Description

Validation Criteria Bibliography Appendix & Glossary

Requirements Validation

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



Requirements ReviewThe primary requirements validation

technique is review:Conducted by both software developer and customerOnce review is completed, SRS is signed off by both the parties.After approval the specification becomes a ‘Contract’ for software development


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?

Requirements Management

GoalRequirements 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.



Analysis Methods & Models

Analysis Method:Structured AnalysisObject-Oriented Analysis

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

Structured Analysis


Object-Oriented Analysis


Requirements Analysis: Structured Techniques



Data Modeling - ERD

Data objects, attributes and relationshipsCardinality and Modality (Crow Foot Notation)Entity Relationship diagram (ERD)

Entity Relationship Entity

Doctor Treats Patient


Data Flow DiagramsGraphical representation that depicts information flow and the transforms that are applied as data moves from input to outputConcepts:

Context Diagram / Level 0 DiagramLevelingBalancingProcess Specification


DFD symbolsProducer/Consumer of information outside the bounds of the systemTransformer of informationData item or collection of data itemsRepository of data stored for one or more processes

External Entity

Process

DataItem

Data Store


State Transition Diagrams

Represent states of the system

Transitions between states; activities that trigger state change

State

Requirements Analysis: Object-Oriented

Techniques


Object Model

Basic class model includes name, attributes, & operations

Inheritance


ClassName

Attribute 1Attribute 2Attribute N

Operation 1Operation N

Subclass1 Subclass2

Superclass

discriminator

Object ModelAggregation

Multiplicity of Associations


Part1-Class

AssemblyClass

Part2-Class

Class

Class

Class

Exactly one

Many/Optional

One or more1..*

Object Modeling StepsIdentify objects and classesPrepare a data dictionaryIdentify associations between objectsIdentify attributes of objects and linksOrganize and simplify object classes using inheritanceVerify that access paths exist for likely queriesIterate and refine the modelGroup classes into modules
