Requirements Analysis SJTU

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

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

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

Subtopics Requirements classification Conceptual modeling Requirements negotiation

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

Subtopics Requirements classification Conceptual modeling Requirements negotiation

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]

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

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

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

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

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)

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

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

Subtopics Requirements classification Conceptual modeling Requirements negotiation

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

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

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

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

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