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
Requirement Engineering, Analysis, Specification & Modeling 3
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.
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 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
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 methodNon-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 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
Requirement Engineering, Analysis, Specification & Modeling 9
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.
Requirement Engineering, Analysis, Specification & Modeling 10
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
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(ORDER-ID) 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 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
Requirement Engineering, Analysis, Specification & Modeling 13
Classification of Functional Requirements
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, Analysis, Specification & Modeling 14
Classification of Functional Requirements
Requirement Engineering, Analysis, Specification & Modeling 15
Requirement Engineering, Analysis, Specification & Modeling 16
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.
Requirement Engineering, Analysis, Specification & Modeling 17
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
Requirement Engineering, Analysis, Specification & Modeling 18
Requirement Engineering, Analysis, Specification & Modeling 19
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.
Requirement Engineering, Analysis, Specification & Modeling 20
Requirements AnalysisTasks
Problem RecognitionEvaluation and SynthesisModelingSpecificationReview
Requirement Engineering, Analysis, Specification & Modeling 21
Requirement Engineering, Analysis, Specification & Modeling 22
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
Requirement Engineering, Analysis, Specification & Modeling 23
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
Requirement Engineering, Analysis, Specification & Modeling 24
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.
Requirement Engineering, Analysis, Specification & Modeling 25
Requirement Engineering, Analysis, Specification & Modeling 26
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
Requirement Engineering, Analysis, Specification & Modeling 27
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.
Requirement Engineering, Analysis, Specification & Modeling 28
Requirement Engineering, Analysis, Specification & Modeling 29
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
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
Requirement Engineering, Analysis, Specification & Modeling 33
Data Modeling - ERD
Data objects, attributes and relationshipsCardinality and Modality (Crow Foot Notation)Entity Relationship diagram (ERD)
Entity Relationship Entity
Doctor Treats Patient
Requirement Engineering, Analysis, Specification & Modeling 34
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
Requirement Engineering, Analysis, Specification & Modeling 35
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
Requirement Engineering, Analysis, Specification & Modeling 36
State Transition Diagrams
Represent states of the system
Transitions between states; activities that trigger state change
State
Requirements Analysis: Object-Oriented
Techniques
Requirement Engineering, Analysis, Specification & Modeling 37
Object Model
Basic class model includes name, attributes, & operations
Inheritance
Requirement Engineering, Analysis, Specification & Modeling 38
ClassName
Attribute 1Attribute 2Attribute N
Operation 1Operation N
Subclass1 Subclass2
Superclass
discriminator
Object ModelAggregation
Multiplicity of Associations
Requirement Engineering, Analysis, Specification & Modeling 39
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
Requirement Engineering, Analysis, Specification & Modeling 40