Requirements Engineering A Roadmap Jichuan Chang [email protected] Based on “RE roadmap” by Nuseibeh & Easterbrook RE course materials by Steve Easterbrook http://www.cs.toronto.edu/~sme/CSC2106S/index.html 11/7/2015
Download ReportTranscript Requirements Engineering A Roadmap Jichuan Chang [email protected] Based on “RE roadmap” by Nuseibeh & Easterbrook RE course materials by Steve Easterbrook http://www.cs.toronto.edu/~sme/CSC2106S/index.html 11/7/2015
Requirements Engineering A Roadmap
Jichuan Chang [email protected]
Based on
“RE roadmap” by Nuseibeh & Easterbrook RE course materials by Steve Easterbrook http://www.cs.toronto.edu/~sme/CSC2106S/index.html
4/29/2020 1
Outline
Foundations
What is RE? Why important? Inter-disciplinary aspects of RE Basic Requirements Engineering activities Directions and Discussion
4/29/2020 2
Discussion
About requirements: What and How? Environment and Machine Is there always a bridge from the real-world to the “ machine ” ?
Is formal specification suitable for all requirements?
About RE: Is RE really important? Who can benefic from RE?
What is really used in practice?
Why so many methods/techniques? How to evaluate and choose? What ’ s the process that integrates methods and activities?
RE tools? Traceability?
Future directions: What ’ s the impact of imperfect requirements?
inconsistency? incomplete? evolving?
What ’ s the impact to other development activities?
What ’ s the impact of architectural decision to NFRs?
What ’ s the impact of requirement reuse?
4/29/2020 3
What is RE?
What’s Requirement?
[IEEE Std] A condition or capability needed by a user to solve a problem or achieve an objective. The set of all requirements forms the basis for subsequent development of the system or system component. What is RE? [Zave94] Requirements Engineering is the branch of systems engineering concerned with real-world goals for, services provided by, and constraints on software systems. Requirements Engineering is also concerned with the relationship of these factors to precise specifications of system behavior and to their evolution over time and across system families.
4/29/2020 4
Importance of Requirements
Engineering Argument
A good solution can only be developed if the engineer has a solid understanding of the problem.
Economic Argument
Defects are cheaper to remove if are found earlier.
Empirical Argument
Failure to understand and manage requirements is the biggest single cause of cost and schedule over-runs.
Safety Argument
Safety-related software errors arise most often from inadequate or misunderstood requirements … … 4/29/2020 5
Research on RE
Early research:
One epigram summarized all of RE.
Reqts. say what the system will do and not how it will do it.
A time-consuming, bureaucratic & contractual process?
1990
’
s:
A field of study of it own right Two series of international meetings: RE and ICRE International journal by Springer.
Late 1990
’
s:
Grown up enough Many additional smaller meetings and workshops Emphasize the use of contextualized enquiry techniques Model indicative & optative properties of the environment Handle inconsistent and evolving specification
Future:
increasingly recognized as a critical activity 4/29/2020 6
RE Basics
Dimensions of RE What vs. How
What does a web browser do?
‘What’ refers to a system’s purpose external to the system A property of the application domain ‘How’ refers to a system’s structure & behavior internal to the system A property of the machine domain
Foundations of RE – Multi-discipline
Systems Theory, Systems Engineering, Math & Logic, Computer Science, Social Sciences, Cognitive Sciences, Philosophy, AI 4/29/2020 7
RE process
RE in software lifecycle
Initial phase may also span the entire life cycle
Essential RE process
Understand the problem elicitation Formally describe the problem specification, modeling Attain agreement on the nature of problem validation, conflict resolution, negotiation requirements management - maintain the agreement!
Sequential or iterative/incremental
RE groundwork
Feasibility, risk, concept of operations Decide the RE process, methods and techniques 4/29/2020 8
Outline
Foundations
Basic Requirements Engineering activities
Eliciting Requirements Modeling and Analyzing Requirements Communicating Requirements Agreeing Requirements Evolving Requirements RE Tool
Directions and Discussion
4/29/2020 9
Eliciting Requirements
Source of Requirements: Customer-driven, Market driven, Hybrid Affect the role of Requirements Things to elicit System boundaries Stakeholders & User Classes Viewpoints Goals and tasks Scenarios/Use cases Elicitation techniques Interviews, questionnaires, surveys, meetings Prototyping Ethnographic techniques Knowledge elicitation techniques Conversation Analysis Text Analysis Elicitation process: Inquiry cycle Use case analysis 4/29/2020 Ethnographic: a branch of sociology dealing with nonspecialists' commonsense understanding of the structure and organization of society 10
Modeling Requirements
Why Modeling?
Modeling can guide elicitation it help you ask the right questions?
Modeling can provide a measure of progress: if we’ve filled in all the pieces of the model, are we done?
Modeling can help to uncover problems Does inconsistency in the model reveal interesting things…?
conflicting or infeasible requirements; confusion over terminology, scope, etc; reveal disagreements between stakeholders Modeling can help us check our understanding Can we test that the model has the properties we expect?
Can we reason over the model to understand its consequences?
Can we animate the model to help us visualize/validate the requirements?
4/29/2020 11
Modeling Techniques
Modeling Enterprises Goals & objectives Organizational structure Processes and products Agents and work roles Modeling Functional Requirements Structural views Behavioral views Timing requirements Modeling Non-functional Requirements Product requirements Process requirements External requirements Information modeling: ERD Organization modeling: i*, SSM, ISAC Goal modeling: KAOS, CREWS Structured Analysis: SADT, SSADM, JSD Object Oriented Analysis: OOA, OOSE, OMT, UML Formal Methods: SCR, RSML, Z, Larch, VDM Quality tradeoffs: QFD, win-win Specific NFRs: Performance:Timed Petri nets Usability: Task models Reliability: Probabilistic MTTF 4/29/2020 12
Communicating Reqts - SRS
How do we communicate the Requirements to others?
It is common practice to capture them in an SRS Purpose Communicates an understanding of the requirements Contractual Baseline for evaluating subsequent products testing, V&V Baseline for change control Audience Users, Purchasers Requirements Analysts Developers, Programmers Testers Project Managers 4/29/2020 13
SRS for Procurement
An ‘SRS’ may be written by: the procurer (a call for proposals) Must be general enough to yield a good selection of bids … and specific enough to exclude unreasonable bids the bidders (a proposal to meet the CfP) must be specific enough to demonstrate feasibility and competence … and general enough to avoid over-commitment the selected developer reflects the developer’s understanding of the customers needs forms the basis for evaluation of contractual performance or an independent RE contractor Choice over what point to compete the contract Early (conceptual stage) Late (detailed specification stage) IEEE Standard recommends SRS jointly developed by procurer and developer 4/29/2020 14
Reqts Traceability
Importance: Verification & Validation Maintenance Assessing change requests Tracing design rationale Document access Process visibility Management change management risk management control of the development process Difficulties: Cost Delayed gratification Size and diversity 4/29/2020 Current Practice Focuses on baselined requirements Coverage links from requirements forward to designs, code, test cases, links back from designs, code, test cases to requirements links between requirements at different levels Tools (manual, syntactic) ??
Approaches: UID, hypertext linking Ability: Follow links Find missing links Measure overall traceability 15
Agreeing Requirements
Two key problems: validation & negotiation Validation -
What is “truth” and what is “knowable ”?
Approaches (Based on philosophical assumptions): assumes there is an objective problem that exists in the world design your requirements models to be refutable validation is always subjective and contextualised Method in practice: Inspections, Reviews and Walkthroughs Prototyping: Throwaway or Evolve?
Negotiation -
How to reconcile conflicting goals?
Requirements Negotiation Competition Third Party Resolution Bidding and Bargaining 4/29/2020 16
Evolving Requirements
Software evolves because requirements evolve …
How to manage incremental change to reqts models?
How can multiple models (specifications) be compared?
How to capture the rationale for each change?
Traditional change management
Add, modify, remove requirements during development Baselines, Change Requests, Review Boards
Software Families
The product line approach
Viewpoints
Requirements model is a collection of viewpoints as a framework for understanding requirements evolution Viewpoints are instantiated from viewpoint templates Viewpoints contain consistency rules (no central control) Internal rule, External rule, Work plan 4/29/2020 17
RE Tool examples
Requisite Pro
http://www.rational.com/ products/reqpro/ Support Unified Process Support use-case based, declarative, and mixed representation (document templates) Support Requirements Traceability Integrated with change mgmt, modeling, testing, metrics and project mgmt tools.
DOORS
http://www.telelogic.com/doors/ Support Requirements Traceability Inter-project linking, Multiple Views Integration with MS Office and external communication tools
Cradle
http://www.threesl.com/ 4/29/2020 18
Outline Foundations Basic Requirements Engineering activities
Directions and Discussion
4/29/2020 19
Future Research Directions Trends in the 1990’s
Handle inconsistent and evolving specification Future Directions: Emphasize the use of contextualized enquiry techniques Model indicative & optative properties of the environment Modeling and analysis of problem domain, as opposed to the behavior of software.
Models for non-functional requirements (NFR).
Bridging the gap between contextual enquiry and formal specification techniques.
Impact of architectural choices on the prioritization and evolution of requirements.
Reuse of requirements models to facilitate the development of system families and COTS selection.
Multi-disciplinary training for requirements practitioners.
4/29/2020 20
Discussion
About requirements: What and How? Environment and Machine Is there always a bridge from the real-world to the “ machine ” ?
Is formal specification suitable for all requirements?
About RE: Is RE really important? Who can benefic from RE?
What is really used in practice?
Why so many methods/techniques? How to evaluate and choose? What ’ s the process that integrates methods and activities?
RE tools? Traceability?
Future directions: What ’ s the impact of imperfect requirements?
inconsistency? incomplete? evolving?
What ’ s the impact to other development activities?
What ’ s the impact of architectural decision to NFRs?
What ’ s the impact of requirement reuse?
4/29/2020 21