Chapter 02 Requirements Engineering

Chapter 02 Requirements Engineering
Problems with requirements practices Requirements engineering tasks Inception Elicitation Elaboration Negotiation Specification Validation Requirements management By Prof R.P. Sabale

The Problems with our Requirements Practices
We have trouble understanding the requirements that we do acquire from the customer We often record requirements in a disorganized manner We spend far too little time verifying what we do record We allow change to control us, rather than establishing mechanisms to control change Most importantly, we fail to establish a solid foundation for the system or software that the user wants built (more on next slide) By Prof R.P. Sabale

The Problems with our Requirements Practices (continued)
Many software developers argue that Building software is so compelling that we want to jump right in (before having a clear understanding of what is needed) Things will become clear as we build the software Project stakeholders will be able to better understand what they need only after examining early iterations of the software Things change so rapidly that requirements engineering is a waste of time The bottom line is producing a working program and that all else is secondary All of these arguments contain some truth, especially for small projects that take less than one month to complete However, as software grows in size and complexity, these arguments begin to break down and can lead to a failed software project By Prof R.P. Sabale

A Solution: Requirements Engineering
Begins during the communication activity and continues into the modeling activity Builds a bridge from the system requirements into software design and construction Allows the requirements engineer to examine the context of the software work to be performed the specific needs that design and construction must address the priorities that guide the order in which work is to be completed the information, function, and behavior that will have a profound impact on the resultant design By Prof R.P. Sabale

Requirements Engineering Tasks
Seven distinct tasks Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management Some of these tasks may occur in parallel and all are adapted to the needs of the project All strive to define what the customer wants All serve to establish a solid foundation for the design and construction of the software By Prof R.P. Sabale

Example Project: Campus Information Access Kiosk
Both podium-high and desk-high terminals located throughout the campus in all classroom buildings, admin buildings, labs, and dormitories Hand/Palm-login and logout (seamlessly) Voice input Optional audio/visual or just visual output Immediate access to all campus information plus Cell phone voice messaging By Prof R.P. Sabale

Inception Elicitation Elaboration Negotiation Specification Validation
Requirements Management By Prof R.P. Sabale

Inception Task During inception, the requirements engineer asks a set of questions to establish… A basic understanding of the problem The people who want a solution The nature of the solution that is desired The effectiveness of preliminary communication and collaboration between the customer and the developer Through these questions, the requirements engineer needs to… Identify the stakeholders Recognize multiple viewpoints Work toward collaboration Break the ice and initiate the communication By Prof R.P. Sabale

The First Set of Questions
These questions focus on the customer, other stakeholders, the overall goals, and the benefits Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution that you need? By Prof R.P. Sabale

The Next Set of Questions
These questions enable the requirements engineer to gain a better understanding of the problem and allow the customer to voice his or her perceptions about a solution How would you characterize "good" output that would be generated by a successful solution? What problem(s) will this solution address? Can you show me (or describe) the business environment in which the solution will be used? Will special performance issues or constraints affect the way the solution is approached? By Prof R.P. Sabale

The Final Set of Questions
These questions focus on the effectiveness of the communication activity itself Are you the right person to answer these questions? Are your answers "official"? Are my questions relevant to the problem that you have? Am I asking too many questions? Can anyone else provide additional information? Should I be asking you anything else? By Prof R.P. Sabale

Elicitation Task Eliciting requirements is difficult because of
Problems of scope in identifying the boundaries of the system or specifying too much technical detail rather than overall system objectives Problems of understanding what is wanted, what the problem domain is, and what the computing environment can handle (Information that is believed to be "obvious" is often omitted) Problems of volatility because the requirements change over time Elicitation may be accomplished through two activities Collaborative requirements gathering Quality function deployment By Prof R.P. Sabale

Basic Guidelines of Collaborative Requirements Gathering
Meetings are conducted and attended by both software engineers, customers, and other interested stakeholders Rules for preparation and participation are established An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas A "facilitator" (customer, developer, or outsider) controls the meeting A "definition mechanism" is used such as work sheets, flip charts, wall stickers, electronic bulletin board, chat room, or some other virtual forum The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements By Prof R.P. Sabale

Quality Function Deployment
This is a technique that translates the needs of the customer into technical requirements for software It emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process through functions, information, and tasks It identifies three types of requirements Normal requirements: These requirements are the objectives and goals stated for a product or system during meetings with the customer Expected requirements: These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them Exciting requirements: These requirements are for features that go beyond the customer's expectations and prove to be very satisfying when present By Prof R.P. Sabale

Elicitation Work Products
The work products will vary depending on the system, but should include one or more of the following items A statement of need and feasibility A bounded statement of scope for the system or product A list of customers, users, and other stakeholders who participated in requirements elicitation A description of the system's technical environment A list of requirements (organized by function) and the domain constraints that apply to each A set of preliminary usage scenarios (in the form of use cases) that provide insight into the use of the system or product under different operating conditions Any prototypes developed to better define requirements By Prof R.P. Sabale

Elaboration Task During elaboration, the software engineer takes the information obtained during inception and elicitation and begins to expand and refine it Elaboration focuses on developing a refined technical model of software functions, features, and constraints It is an analysis modeling task Use cases are developed Domain classes are identified along with their attributes and relationships State machine diagrams are used to capture the life on an object The end result is an analysis model that defines the functional, informational, and behavioral domains of the problem By Prof R.P. Sabale

Developing Use Cases Step One – Define the set of actors that will be involved in the story Actors are people, devices, or other systems that use the system or product within the context of the function and behavior that is to be described Actors are anything that communicate with the system or product and that are external to the system itself Step Two – Develop use cases, where each one answers a set of questions (More on next slide) By Prof R.P. Sabale

Questions Commonly Answered by a Use Case
Who is the primary actor(s), the secondary actor(s)? What are the actor’s goals? What preconditions should exist before the scenario begins? What main tasks or functions are performed by the actor? What exceptions might be considered as the scenario is described? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? By Prof R.P. Sabale

Elements of the Analysis Model
Scenario-based elements Describe the system from the user's point of view using scenarios that are depicted in use cases and activity diagrams Class-based elements Identify the domain classes for the objects manipulated by the actors, the attributes of these classes, and how they interact with one another; they utilize class diagrams to do this Behavioral elements Use state diagrams to represent the state of the system, the events that cause the system to change state, and the actions that are taken as a result of a particular event; can also be applied to each class in the system Flow-oriented elements Use data flow diagrams to show the input data that comes into a system, what functions are applied to that data to do transformations, and what resulting output data are produced By Prof R.P. Sabale

Negotiation Task During negotiation, the software engineer reconciles the conflicts between what the customer wants and what can be achieved given limited business resources Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders Risks associated with each requirement are identified and analyzed Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction By Prof R.P. Sabale

The Art of Negotiation Recognize that it is not competition
Map out a strategy Listen actively Focus on the other party’s interests Don’t let it get personal Be creative Be ready to commit By Prof R.P. Sabale

Specification Task A specification is the final work product produced by the requirements engineer It is normally in the form of a software requirements specification It serves as the foundation for subsequent software engineering activities It describes the function and performance of a computer-based system and the constraints that will govern its development It formalizes the informational, functional, and behavioral requirements of the proposed software in both a graphical and textual format By Prof R.P. Sabale

Typical Contents of a Software Requirements Specification
Required states and modes Software requirements grouped by capabilities (i.e., functions, objects) Software external interface requirements Software internal interface requirements Software internal data requirements Other software requirements (safety, security, privacy, environment, hardware, software, communications, quality, personnel, training, logistics, etc.) Design and implementation constraints Qualification provisions to ensure each requirement has been met Demonstration, test, analysis, inspection, etc. Requirements traceability Trace back to the system or subsystem where each requirement applies By Prof R.P. Sabale

Validation Task During validation, the work products produced as a result of requirements engineering are assessed for quality The specification is examined to ensure that all software requirements have been stated unambiguously inconsistencies, omissions, and errors have been detected and corrected the work products conform to the standards established for the process, the project, and the product The formal technical review serves as the primary requirements validation mechanism Members include software engineers, customers, users, and other stakeholders By Prof R.P. Sabale

Questions to ask when Validating Requirements
Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? (more on next slide) By Prof R.P. Sabale

Questions to ask when Validating Requirements (continued)
Do any requirements conflict with other requirements? Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Approaches: Demonstration, actual test, analysis, or inspection Does the requirements model properly reflect the information, function, and behavior of the system to be built? Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system? By Prof R.P. Sabale

Requirements Management Task
During requirements management, the project team performs a set of activities to identify, control, and track requirements and changes to the requirements at any time as the project proceeds Each requirement is assigned a unique identifier The requirements are then placed into one or more traceability tables These tables may be stored in a database that relate features, sources, dependencies, subsystems, and interfaces to the requirements A requirements traceability table is also placed at the end of the software requirements specification By Prof R.P. Sabale

Summary Inception Elicitation Elaboration Negotiation Specification
Validation Requirements Management By Prof R.P. Sabale 

By Prof R.P. Sabale

Software Process Prof. Ing. Ivo Vondrak, CSc.
Dept. of Computer Science Technical University of Ostrava By Prof R.P. Sabale

References Kruchten, P.: The Rational Unified Process: An Introduction, Third Edition, Addison-Wesley Pearson Education, Inc., NJ, 2004 Humphrey, W. Managing the Software Process, Addison-Wesley/SEI series in Software Engineering, Reading, Ma, 1989 Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Software Development Process, Addison Wesley Longman, Inc., 1999 Booch, G., Jacobson, I., Rumbaugh, J.: The Unified Modeling Language User Guide, Addison Wesley Longman, Inc., 1999 IBM Corporation, Rational University: PRJ270: Essentials of Rational Unified Process, USA, 2003 By Prof R.P. Sabale

Contents Introduction Software Process Process Disciplines Conclusions
Layout of Software Development, Definition of the Process, Capability Maturity Model Software Process Software Development Best Practices, Rational Unified Process, Process Description, Iterative Development, Architecture-Centric Development, Use-Case-Driven Development Process Disciplines Business Modeling, Requirements, Analysis and Design, Implementation, Testing, Deployment, Project Management, Configuration and Change Management, Environment Conclusions By Prof R.P. Sabale

Introduction Layout of Software Development Definition of the Process
Capability Maturity Model By Prof R.P. Sabale

Software Production Layout
Software Process Project instantiated by Project Project consists of consists of Project Execution Analysis Design Implementation Test Project Management Planning Control uses uses Project Management Methodology System of methods for software product development Software Development Methodology System of methods for project management is a is a By Prof R.P. Sabale

A Definition of Process
The means by which people, procedures, methods, equipment, and tools are integrated to produce a desired end result. B A D C Relationships of all tasks PROCESS Skills, Training, Motivation, & Management Tools By Prof R.P. Sabale Source: Software Engineering Institute, Carnegie Mellon University

Software Process W. Humphrey and P. Feiler: A process is a set of partially ordered steps intended to reach a goal..."(to produce and maintain requested software deliverables). A software process includes sets of related artifacts, human and computerized resources, organizational structures and constraints. PEOPLE PROCESS TECHNOLOGY Major determinants of software cost, schedule, and quality performance By Prof R.P. Sabale

Capability Maturity Model (CMM)
By Prof R.P. Sabale

Visibility into Software Process
1 In Out 2 In Out 3 In Out 4 In Out 5 In Out By Prof R.P. Sabale

Software Process Software Development Best Practices
Rational Unified Process Process Description Iterative Development Architecture-Centric Development Use-Case-Driven Development By Prof R.P. Sabale

What’s Up?! G. Booch: The bad news is that the expansion of the software systems in size, complexity, distribution, and importance pushes the limits of what we in the software industry know how to develop. Trying to advance legacy systems to more modern technology brings its own set of technical and organizational problems. Compounding the problem is that businesses continue to demand increased productivity and improved quality with faster development and demployment. Additionally, the supply of qualified development personnel is not keeping pace with demand. The net result is that building and maintaining software is hard and getting harder; building quality software in a repeatable and predictable is harder still. By Prof R.P. Sabale

Symptoms of Software Development Problems
Inaccurate understanding of end-user needs Inability to deal with changing requirements Modules don’t integrate It is difficult to maintain or extend the software Late discovery of flaws Poor quality and performance of the software No coordinated team effort Build-and-release issues Unfortunately, treating these symptoms does not treat the disease! By Prof R.P. Sabale

Root Causes Insufficient requirements specification and their ad hoc management Ambiguous and imprecise communication Brittle architecture Overwhelming complexity Undetected inconsistencies in requirements, design, and implementation Poor and insufficient testing Subjective assessment of project status Failure to attack risk Uncontrolled change propagation Insufficient automation To treat these root causes eliminates the symptoms and enables to develop and maintain software in a repeatable and predictable way. By Prof R.P. Sabale

Software Best Practices
Commercially proven approaches to software development that, when used in combination, strike at the root causes of software development problems.* Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software By Prof R.P. Sabale * See the Software Program Manager’s Network best practices work at

Tracing Symptoms to Root Causes and Best Practices
Inaccurate understanding of end-user needs Inability to deal with changing requirements Modules don’t integrate It is difficult to maintain or extend the software Late discovery of flaws Poor quality and performance of the software No coordinated team effort Build-and-release issues Insufficient requirements specification and their ad hoc management Ambiguous and imprecise communication Brittle architecture Overwhelming complexity Undetected inconsistencies in requirements, design, and implementation Poor and insufficient testing Subjective assessment of project status Failure to attack risk Uncontrolled change propagation Insufficient automation Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software By Prof R.P. Sabale

Develop Software Iteratively
Classic software development processes follow the waterfall lifecycle. Development proceeds linearly from requirements analysis, through design, implementation, and testing. Requirements analysis It takes too long to see results. It depends on stable, correct requirements. It delays the detection of errors until the end. It does not promote software reuse and prototyping. Software Design Implementation (coding) Testing and deployment By Prof R.P. Sabale

Iterative and Incremental Process
This approach is one of continuous discovery, invention, and implementation, with each iteration forcing the development team to drive the desired product to closure in a predictable and repeatable way. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. By Prof R.P. Sabale

Solutions to Root Causes
Serious misunderstandings are made visible early This approach enables user feedback The development team is forced to focus on most critical issues Continuous testing enables an objective assessment of the project status Inconsistencies among requirements, design, and implementation are detected early The workload of the team is spread more evenly during project lifecycle The team can leverage lessons learned and improve the process Stakeholders can be given concrete evidence of the project status By Prof R.P. Sabale

Manage Requirements A requirement is a condition or capability a system must have. It is a real problem to capture all requirements before the start of development. Requirements change during project lifecycle. Understanding and identifying of requirements is a continuous process. The active management of requirements is about following three activities: eliciting, organizing, and documenting the system required functionality and constraints. By Prof R.P. Sabale

A disciplined approach is built into requirements management Communication is based on defined requirements Requirements have to be prioritized, filtered, and traced An objective assessment of functionality is possible Inconsistencies are detected more easily With a tool support it is possible to provide a repository for system requirements By Prof R.P. Sabale

Use Component-Based Architectures
Component-based development is an important approach how to build resilient software architecture because it enables the reuse of components from many available sources. Components make reuse possible on a larger scale, enabling systems to be composed from existing parts, off-the-shelf third-party parts, and a few new parts that address the specific domain and integrate the other parts together. Iterative approach involves the continuous evolution of the system architecture. Each iteration produces an executable architecture that can be measured, tested, and evaluated against the system requirements. By Prof R.P. Sabale

Components facilitate resilient architectures Modularity enables a clear separation of system elements that are subject to change Reuse is facilitated by leveraging standardized frameworks (COM, CORBA, EJB …) and commercially available components Components provide a natural basis for configuration management Visual modeling tools provide automation for component-based development By Prof R.P. Sabale

Visually Model Software
A model is a simplification of reality that completely describes a system from a particular perspective. Activity Diagrams Models Sequence Collaboration Statechart Deployment Component Object Class Use-Case Static Diagrams Dynamic Diagrams By Prof R.P. Sabale Visual modeling with UML

Visual Modeling Using UML
Class Diagrams Use-Case Diagrams Object Diagrams Sequence Diagrams Collaboration Diagrams Component Diagrams Models Forward and Reverse Engineering Deployment Diagrams Statechart Diagrams Activity Diagrams UML Diagrams Target System By Prof R.P. Sabale

Use cases and scenarios unambiguously specify behavior Software design is unambiguously captured by models Details can be hidden when needed Unambiguous design discovers inconsistencies more readily Application quality begins with good design Visual modeling tools provide support for UML modeling By Prof R.P. Sabale

Continuously Verify Software Quality
Software problems are exponentially more expensive to find and repair after deployment than beforehand. Verifying system functionality involves creating test for each key scenario that represents some aspect of required behavior. Since the system is developed iteratively every iteration includes testing = continuous assessment of product quality. Cost By Prof R.P. Sabale Time

Testing Dimensions of Quality
Functionality Test the accurate workings of each usage scenario Supportability Usability Test the ability to maintain and support application under production use Test application from the perspective of convenience to end-user. Performance Reliability Test online response under average and peak loading Test that the application behaves consistently and predictably. By Prof R.P. Sabale

Project status assessment is made objective because test results are continuously evaluated This objective assessment exposes inconsistencies in requirements, design and implementation Testing and verification is focused on most important areas Defects are identified early and thus the costs of fixing them are reduced Automated testing tools provide testing for functionality, reliability, and performance By Prof R.P. Sabale

Control Changes to Software
The ability to manage change - making certain that each change is acceptable, and being able to track changes - is essential in an environment in which change is inevitable. Maintaining traceability among elements of each release is essential for assessing and actively managing the impact of change. In the absence of disciplined control of changes, the development process degenerates rapidly into chaos. By Prof R.P. Sabale

The workflow of requirements changes is defined and repeatable Change requests facilitate clear communication Isolated workspaces reduce interferences among team members working in parallel Workspaces contain all artifacts, which facilitates consistency Change propagation is controlled Changes can be maintained in a robust system By Prof R.P. Sabale

The Rational Unified Process
The Rational Unified Process® (RUP) is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. RUP is a process product. It is developed and maintained by Rational Software and integrated with its suite of software development tools available from IBM. RUP is a process framework that can be adapted and extended to suit the needs of an adopting organization. RUP captures many of best practices mentioned before (develop software iteratively, manage requirements, use component-based architectures, visually model software, continuously verify software quality, control changes to software). By Prof R.P. Sabale

Two Dimensions of the Process
Dynamic aspect of the process as it is enacted: it is expressed in terms of cycles, phases, iterations, and milestones – organization along time Static aspect of the process: how it is described in terms of activities, artifacts, workers and workflows – organization along content By Prof R.P. Sabale

Process Description Static structure of the process describes who is doing what, how, and when. The RUP is represented using following primary elements: Roles: the who Activities: the how Artifact: the what Workflow: the when A discipline is the collection of above mentioned kinds of elements. By Prof R.P. Sabale

Roles Role defines the behavior and responsibilities of an individual (designer, analyst, programmer ...), or a group of individuals working together as a team. The behavior is expressed in terms of activities the role performs, and each role is associated with a set of cohesive activities. The responsibilities of each role are usually expressed in relation to certain artifact that the role creates, modifies, or control. Roles are not individuals, nor job titles. One can play several roles in process. By Prof R.P. Sabale

Activities An activity is a unit of work that an individual in that role may be asked to perform and that produces a meaningful result in the context of the project. The granularity of an activity may vary from hours to days. It usually involves one person in the associated role and affects one or only small number of artifacts. Activities may be repeated several times on the same artifact, especially from one iteration to another. By Prof R.P. Sabale

Artifacts Deliverables are only the subset of other artifacts.
Artifacts are things that are produced, modified, or used by a process (model, document, source code, executables …). Deliverables are only the subset of other artifacts. Artifacts are very likely to be subject to version control and configuration management. Sets of Artifacts: Management set – planning and operational artifacts Requirements set – the vision document and requirements in the form of stakeholders’ needs Design set – the design model and architecture description Implementation set – the source code and executables, the associated data files Deployment set – installation instructions, user documentation, and training material By Prof R.P. Sabale

Major Artifacts Stakeholder Requests Risk List Business Case Vision
Software Development Plan Supplementary Specification Glossary Software Architecture Document Deployment Plan Use-Case Model Test Plan Software Requirements Specification Product Analysis Model Design Model Implementation Model By Prof R.P. Sabale

Resources, Roles and Activities
Object design Architectural analysis Architectural design Coding Activities Architectural Board Designer Programmer Roles Resources Richard John Mary Laura By Prof R.P. Sabale

Workflows Workflows are sequences of activities that produce results of observable value (business modeling, implementation …). Core Workflow gives the overall flow of activities for each discipline. Workflow Details show roles, activities they perform, input artifacts they need, and output artifacts they produce. Iteration Plan is time-sequenced set of activities and tasks, with assigned resources, and containing task dependencies. A fine-grained plan, one per iteration. By Prof R.P. Sabale

Example of a Core Workflow
[New system] [Existing System] [New Input] [Can’t Do All the Work] Workflow Detail Analyze the Problem Understand Stakeholder Needs [Incorrect Problem] [Addressing Correct Problem] Manage Changing Requirements [Work in Scope] Define the System Manage the Scope of the System Refine the System Definition By Prof R.P. Sabale

Iterative Development
Given today’s sophisticated software systems, it is not possible to sequentially first define the entire problem, design the entire solution, build the software and then test the product at the end. An iterative approach is required that allows an increasing understanding of the problem through successive refinements, and to incrementally grow an effective solution over multiple iterations. Each iteration ends with an executable release. By Prof R.P. Sabale

The Sequential Process
Many engineering problems are solved using a sequential process: Understand the problem, its requirements and constraints Design a solution that satisfies all requirements Implement the solution using the best engineering techniques Verify that the implementation satisfies the started requirements Deliver: Problem solved! This works perfectly in the area of civil and mechanical engineering where design and construction is based on hundreds of years of experience. The sequential process is based on two wrong assumptions that jeopardize the success of software projects: Requirements will be frozen (user changes, problem changes, underlying technology changes, market changes …) We can get the design right on paper before proceeding (underlying “theories” are week and poorly understood in software engineering, relatively straightforward laws of physics underlie the design of bridge, but there is no strict equivalent in software design – software is “soft”) By Prof R.P. Sabale

Iterative Lifecycle Requirements Design Implementation Testing R D R R
Time By Prof R.P. Sabale

Phases and Milestones The development cycle is divided in four consecutive phases: Inception: a good idea is developed into a vision of the end product and the business case for the product is presented. Elaboration: most of the product requirements are specified and the system architecture is designed. Construction: the product is built – completed software is added to the skeleton (architecture) Transition: the product is moved to user community (beta testing, training …) Inception Elaboration Construction Transition Time Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operation Capability Milestone Product Release Milestone By Prof R.P. Sabale

Development Cycle Each cycle results in a new release of the system, and each is a product ready for delivery. This product has to accommodate the specified needs. Initial development cycle – a software product is created Evolution cycles – a product evolves into its next generation by repetition of the sequences of inception, elaboration, construction, and transition phases. Cycles may overlap slightly: the inception and elaboration phase may begin during the final part of the transition phase of the previous cycle. I 10% E 30% C 50% T 10% By Prof R.P. Sabale Typical time line for initial development cycles

Phases and Iterations Each phase can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. Scope and Business Case agreement Architecture baselined Product sufficiently mature for customers to use Acceptance or end of life LCO LCA IOC PR Inception Elaboration Construction Transition Time Preliminary Iteration Architecture Iteration Architecture Iteration Developm. Iteration Developm. Iteration Developm. Iteration Transit. Iteration Transit. Iteration Internal Release Minor Milestone First External Release (e.g. beta) Final Release By Prof R.P. Sabale

Duration of an Iteration
An iteration starts with planning and requirements and finishes with an internal or external release. Ideal duration of an iteration is from two to six weeks, depending on your project size and complexity. Factors that affect duration of an iteration: Size, stability and maturity of organization Familiarity with the iterative process Size of project Technical simplicity of project Level of automation used to manage code, distribute information, perform testing By Prof R.P. Sabale

Number of Iterations Phase Low Medium High Inception 1 Elaboration 2 3
1 Elaboration 2 3 Construction Transition Total 6 9 “Normal” project has 6 ± 3 iteration. By Prof R.P. Sabale

Conditions that Increase Number of Iterations
Inception - working with new functionality, unknown business environment, highly volatile scope, make-buy decisions … Elaboration - working with new system environment (new architectural features), untested architectural elements, need for system prototypes … Construction - lots of code to write and verify, new technology or development tools … Transition - need for alphas and betas, conversions of customer database, incremental delivery to customers … By Prof R.P. Sabale

Inception Phase: Objectives
Establish project scope and boundary conditions, including operational concepts, and acceptance criteria Determine the critical use cases and primary scenarios of behavior that drive the system functionality Demonstrate at least one candidate architecture against some of the primary scenarios Estimate the overall cost and schedule for the entire project Identify potential risks (the sources of unpredictability) Prepare the supporting environment for the project By Prof R.P. Sabale

Milestone: Lifecycle Objective (LCO)
Stakeholder concurrence on scope definition and cost and schedule estimates Agreement that the right set of requirements has been captured and that there is a shared understanding of these requirements Credibility of the cost and schedule estimates, priorities, risks, and development process All risks have been identified and a mitigation strategy exists for each Actual expenditures versus planned expenditures By Prof R.P. Sabale

Elaboration Phase: Objectives
Define, validate and baseline the architecture as rapidly as is practical Baseline the vision Baseline a high-fidelity plan for the construction phase Refine support environment Demonstrate that the baseline architecture will support the vision at a reasonable cost in a reasonable time A baseline is a reviewed and approved release of artifacts that constitutes and agreed-on basis for further evolution or development and that can be changed only through a formal procedure. By Prof R.P. Sabale

Milestone: Lifecycle Architecture (LCA)
Product vision and requirements are stable. Architecture is stable. The executable demonstration show that the major risks have been addressed and resolved. Iteration plans for Construction phase is sufficiently detailed to allow work to proceed, and are supported by credible estimates. All stakeholders agree that current vision can be achieved if the current plan is executed to develop the complete system, in the context of the current architecture. Actual resource expenditures versus planned expenditures are acceptable. By Prof R.P. Sabale

Construction Phase: Objectives
Complete the software product for transition to user Minimize development costs by optimizing resources and avoiding unnecessary scrap and rework Achieve adequate quality as rapidly as is practical Achieve useful versions (alpha, beta, and other test releases) as rapidly as possible By Prof R.P. Sabale

Milestone: Initial Operational Capability (IOC)
The product release is stable and mature enough to be deployed in the user community. All the stakeholders are ready for the product’s transition into the user community. The actual resource expenditures versus planned are still acceptable. By Prof R.P. Sabale

Transition Phase: Objectives
Achieve user self-supportability Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision Achieve final product baseline as rapidly and cost-effectively as practical By Prof R.P. Sabale

Milestone: Product Release (PR)
The user is satisfied. Actual resources expenditures versus planned expenditures are acceptable. By Prof R.P. Sabale

Benefits of an Iterative Approach
Risk Mitigation – an iterative process lets developers mitigate risks earlier than a sequential process where the final integration is the only time that risks are discovered or addressed. Accommodating Changes – an iterative process lets developers take into account requirements, tactical and technological changes continuously. Learning as You Go – an advantage of the iterative process is that developers can learn along the way, and the various competencies and specialties are employed during the entire lifecycle. Increased Opportunity for Reuse – an iterative process facilitates reuse of project elements because it is easy to identify common parts as they are partially design and implemented instead of identifying all commonality in the beginning. Better Overall Quality – the system has been tested several times, improving the quality of testing. The requirements have been refined and are related more closely to the user real needs. At the time of delivery, the system has been running longer. By Prof R.P. Sabale

Architecture-Centric Development
A large part of RUP focuses on modeling. Models help developers understand and shape both the problem and the solution. Model is a simplification of reality that help us master a large, complex system that cannot be comprehended easily in its entirety. The model is not the reality, but the best models are the ones that stick very close to reality. Multiple models are needed to address different aspects of the reality. These models must be coordinated to ensure that they are consistent and not too reduntant. By Prof R.P. Sabale

Architecture Models are complete, consistent representation of the system to be built. These models of complex system can be very large! Architecture is the skeleton: “Architecture is what remains when you cannot take away any more things and still understand the system and explain how it works.” Definition: Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.* By Prof R.P. Sabale

Definition of Architecture (RUP)
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition Architecture is part of design; it is about making decisions about how system will be built. But it is not all of design. It stops at the major elements – the elements that have a pervasive and long-lasting effect on the qualities of the system. Architecture is about structure and organization but it also deals with behavior. Architecture does not look only inward but it also looks at the fit of the system in two contexts: the operational and development. It encompasses not only technical aspects but also its economic and sociological aspects. Architecture also addresses “soft” issues such as style and aesthetics. By Prof R.P. Sabale

Architecture Representation
The representation of architecture should allow various stakeholders to communicate and discuss the architecture. The various stakeholders have different concerns and are interested in different aspects of architecture. Architectural view – simplified description (an abstraction) of a system from particular perspectives (e.g.): Logical organization of the system Functionality of the system Concurrency aspects Physical distribution of the software on the underlying platform By Prof R.P. Sabale

Chapter 02 Requirements Engineering

Similar presentations

Presentation on theme: "Chapter 02 Requirements Engineering"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chapter 02 Requirements Engineering

Similar presentations

Presentation on theme: "Chapter 02 Requirements Engineering"— Presentation transcript:

Similar presentations

About project

Feedback