1. Requirements Analysis
SJTU

2. Requirements Engineering Activity Model
Requirements Management
Requirements Elicitation
Requirements Analysis
Requirements Specification
Requirements Validation
Validated Requirements Specification
Existing System Information
Stakeholder Needs
Organizational Standards
Technical Standards
Regulations
Domain Information
Goals

3. Requirements Analysis
The process of analyzing requirements to:
Detect and resolve requirements problems
Decompose (elaborate) requirements
Discover system boundary and how system must interact with its environment
Discover interactions and overlaps between requirements
Gain a better understanding of the problem
Includes the following main activities:
Requirements classification
Conceptual modeling
Requirements negotiation
Quality of analysis directly affects product quality
More rigorous analysis leads to better software quality

4. Typical Requirements Problems
Ambiguous requirements
Conflicting requirements
Design dependent requirements
Infeasible requirements (technical, operational, economic)
Incomplete requirements
Inconsistent requirements
Non-singularized requirements
Non-testable requirements
Unnecessary requirements

5. Subtopics Requirements classification Conceptual modeling
Requirements negotiation

6. Requirements Classification
Analyzing requirements to classify into relevant categories
Functional or non-functional
Product or process
Priority
e.g., mandatory, highly desirable, desirable, or optional
Scope
Extent requirement affects system and subsystems
Requirements with global scope can not be allocated to a discrete component
Stability
Estimation of likelihood of change

7. Subtopics Requirements classification Conceptual modeling
Requirements negotiation

8. Background on Modeling
Modeling is a proven and well-accepted engineering technique
Architectural models (blueprints) in civil engineering
Mathematical models for analysis of physical properties
Effects of wind on buildings
Bandwidth analysis
Economic models
“A model is a simplification of reality created in order to better understand the system being created” [Grady Booch]

9. Conceptual Modeling
Development of models to aid understanding of requirements
A model is an abstract representation of system whose requirements are being analyzed
Model can be used to answer questions about system
Not concerned with initiating design of the solution
In nearly all cases, useful to start by building model of system boundary
Crucial to understanding system’s context in its operational environment
Crucial to identify system’s interfaces to external environment

10. Booch’s Four Principles of Modeling
Choice of models has profound influence on how problem is attacked and how solution is shaped
Choose your models well
Every model may be expressed at different levels of precision
Best models are connected to reality
No single model is sufficient
Every nontrivial system is best approached through a small set of nearly independent models

11. Advantages of Conceptual Modeling (1 of 2)
Facilitates reasoning about system in an organized and precise manner
Allows reviewer’s to validate that modeler’s understanding is correct
Enhances communication between stakeholders and developers
Provides basis for predicting important system characteristics
Development schedule
Performance
Processing sequence

12. Advantages of Conceptual Modeling (2 of 2)
Reduces amount of complexity that must be understood at one time
Consider system from different viewpoints
Consider different parts of system
Understand interactions and relationships between different parts of system
Create a composite model by relating viewpoints
Reduces risk by exposing requirements problems early in life-cycle

13. Examples of Conceptual Models
Activity model (week 7)
Class diagram (week 7)
Context diagram (week 6)
Data flow model (week 14)
Data model (week 14)
Formal model (week 14)
Object model (week 7)
Process model (week 14)
State model (week 7)
Use case model (week 6)

14. Factors Influencing Model Selection
Nature of the problem
Expertise of requirements engineer
Customer process requirements
Developer process requirements
Availability of methods and tools

15. Analysis and Modeling Methods
Models are tightly coupled with methods
Methods define a set of models, a process for deriving these models and rules and guidelines that should apply to the models
Sample of available methods
Structured analysis
Real-time structured analysis
Concurrent object-based real-time analysis (COBRA)
Object-oriented analysis
Jackson system development

16. Subtopics Requirements classification Conceptual modeling
Requirements negotiation

17. Requirements Negotiation
The activity of resolving problems with conflicting requirements
Between stakeholder requirements
Between requirements and resources
Between capabilities and constraints
Includes the following main activities:
Requirements discussion
Stakeholders involved present their views
Requirements prioritization
Disputed requirements are prioritized to identify critical requirements
Requirements agreement
Compromise set of requirements result

18. Negotiation Meetings Information stage Discussion stage
Nature of requirements problems are explained
Discussion stage
Stakeholders involved discuss how problems might be resolved
All interested stakeholders should be given opportunity to comment
Priorities may be assigned to requirements at this stage
Resolution stage
Actions concerning requirement are agreed
Actions may be to delete the requirement, to suggest specific modifications to the requirement, or to elicit further information about the requirement

19. Standards, Metrics, and Tools Supporting Requirements Analysis
Software engineering standards stress need for analysis
Detailed guidance provided only by de-facto modeling standards (e.g., UML)
Required properties (non-functional requirements) are quantified during analysis
Reliability and safety
Many tools supporting conceptual modeling (e.g., Rational Rose)
Few tools supporting conflict identification and requirements negotiation
Win-Win is one available tool

20. Key Points
Requirements elicitation, analysis, and negotiation are iterative, interleaved processes (not waterfall)
Requirements analysis includes three main activities
Requirements classification
Conceptual modeling
Requirements negotiation
A model is an abstract representation
Requirements negotiation is always necessary to resolve requirements conflicts and remove requirements overlaps
Defining system boundary is critical
Quality of analysis directly affects product quality

21. References
Pete Sawyer and Gerald Kotonya, Guide to the Software Engineering Body of Knowledge, Chapter 2, Version 0.95, May 2001, IEEE
Gerald Kotonya and Ian Sommerville, Requirements Engineering: Processes and Techniques, Chapter 3, Wiley, 1998
Ian Sommerville, Software Engineering, 6th Edition, Chapter 7, Addison-Wesley, 2000