ISD Lecture 5 Requirement Analysis: Benefits & Strategies Flashcards
Benefits dependency network (BDN):
The BDN provides the framework for explicitly linking the overall investment objectives and required benefits (the ends) with the business changes (the ways) necessary to deliver those benefits and the essential IT capabilities (the means) that enable these changes.
Requirements engineering (RE):
The broad spectrum of task and techniques that lead to an understanding of requirements (to IT systems).
Requirements engineering is the process of conforming engineering designs to a set of core software requirements. This is critically important for creating accurate results in software engineering.
Problem-based interventions: ends drive
The goal is the target improvements.
Innovation-based interventions: ways and means-driven:
The goal is to discover better ways of working by utilizing or new ways.
Functional requirements
The calculations and information that the systems have to deliver.
Non-funcitonal requirements:
it will be such as security, usability and performance etc.
Two types of investments
Problembased interventions:
ends-driven because the goal is the target improvements. For example, 10% improved productivity in a business process.
Innovationbased intervention:
ways and means-driven because the goal is to discover better ways of working by utilizing IT (the means). For example, how could we benefit from using AI?
Characteristics for Problem-Based Interventions
Clear targets:
When the investment is problem-driven, setting targets is appropriate. The organization can usually identify and quantify the benefits of removing known problems through new IT means and new ways of executing business processes and activities.
Challenge with Problem-Based Interventions
Agreeing on the best combination of ways and means for accomplishing the improvements.
Characteristics for Innovation-Based Interventions (Ways-Based or Means-Based)
- Unclear targets
- Unclear benefits
- Requires creativity
- Requires on-gong learning
- Risk – too much focus on technology
The BDN framework
linking the overall investment objectives and required benefits (the ends) with the
business changes (the ways) necessary to deliver those benefits and
the essential IT capabilities (the means) that enable these changes.
Model: IT enablers (Means) -> Enabling Changes (Ways) -> Business Changes (Ways) -> Benefits (Ends) -> Investments objectives (Ends)
Two types of requirements engineering
Classic requirements engineering,
and
Agile requirements engineering
Req. engineering classic: plan-driven
Analysis -> design -> code -> test
We complete the requirements engineering before we move along
Req. engineering classic: plan-driven - The basic activities
Inception: ask management a set of questions that establish …
• basic understanding of the problem
• the people who want a solution
Elicitation: elicit requirements from all stakeholders
Elaboration: create an analysis model that identifies data, function and behavioral requirements
Negotiation: agree on a deliverable system that is realistic for developers and customers
Specification: can be any one (or more) of the following:
• A written document
• A set of models
• A formal mathematical
• A collection of user scenarios (use-cases)
• A prototype
Validation: a review mechanism that looks for
• errors in content or interpretation
• areas where clarification may be required
• missing information
Requirements management
Inception
Identify stakeholders
• “who else do you think I should talk to?”
• Make a list of all the stakeholders that must be included
Recognize multiple points of view
• Different departments or roles will typically have different, sometimes conflicting requirements
Work toward collaboration
• Identify requirement that all agree on and the requirements that conflicts
Eliciting Requirements
Meetings are conducted and attended by both software engineers and customers:
the goal is • to identify the problem • propose elements of the solution • negotiate different approaches, and • specify a preliminary set of solution requirements
Typical Elicitation Work Products
a list of requirements (preferably organized by function) and the domain constraints that apply to each.
Eliciting Functional requirements
Use-Cases
A collection of user scenarios that describe the thread of usage of a system
Each scenario answers the following questions:
• Who is the primary actor, the secondary actor (s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
Use-Case diagram
Elaboration : Building the Analysis Model
Building a model that describes the functions, the data, behavioral aspects in the system.
Negotiating Requirements
Key stakeholders will be involved in the negotiation
Determine each of the stakeholders “win conditions”
• Win conditions are not always obvious
Negotiate
• Work toward a set of requirements that lead to “win-win”
Validating Requirements
Is each requirement consistent
Have all requirements been specified at the proper level of abstraction?
Is the requirement really necessary
Is each requirement bounded and unambiguous?
Is each requirement achievable
Is each requirement testable, once implemented
Requirements management
Is the management effort focusing at:
Managing all changes to the requirements
Req. engineering : agile
Each iteration contains requirement engineering activities
agile Development model, with short iterations feature planing dynamic prioritization feedback and change teamwork customer collaboration
Why Agile RE
Rapid changes:
• Changes in: competitive threats, stakeholder preferences, software technology, time-to-market pressures etc.
• Makes requirements evolve or become obsolete: Requirements tend to evolve very quickly and become obsolete even before project completion.
Agile req asumptions
The changing-requirements assumption:
Requirements always evolve
The documentation assumption:
Developing extensive documentation and models is counterproductive
The customer interaction assumption:
Customers are available for frequent interaction with the developers.
The cost-of-change assumption:
The cost of making changes to the system does not dramatically increase over time.
Classic req assumptions
The assumptions underlying RE in traditional development include the following:
• The customer is able to specify all his/her needs in the initial phase.
• One or more stakeholders are in charge of the requirements gathering activity.
• The development team can readily understand customer needs.
• The structure of the organizations is hierarchical, and there is a sharp separation of the different functions.
Agile RE practices
Six agile practices:
• Face-to-face communication over written specifications,
• iterative RE,
• managing requirements change through constant planning,
• extreme requirements prioritization,
• prototyping, and
• review meetings and tests.
Face-to-face communication over written specifications
Simple techniques such as user stories are used to define high-level requirements.
User story:
• As a so that I can .
• As a cyclist , I want to register my routes, so I can invite other cyclist to join me when training
The effectiveness of this practice heavily depends on the intensive interaction between customers and developers.
A short daily meeting between the team and the customer is another mechanism used to enhance communication.
Iterative Requirements engineering
In agile development, requirements are not pre-defined; instead they emerge during the development process.
Requirement prioritization
Prioritization is essential in requirements analysis, especially for projects that have limited resources in terms of budget, staff and schedule
Requirements can be categorized from the standpoint of importance into
• essential requirements,
• useful capabilities and
• desirable capabilities
Managing requirements change through constant planning
A core principle in agile software development is to adapt and react quickly to changes demanded by the environment.
Prototyping
One of the fastest ways to settle requirements specifications seems to be the development of a prioritized list of features.
Use review meetings and acceptance tests
Agile approaches use frequent review meetings for requirements validation. At the end of each development cycle, a meeting that involves developers, customers, Quality Assurance (QA), management and other stakeholders is scheduled.
Agile RE challenges
Problems with cost and schedule estimation:
The agile approach towards RE makes the estimation of costs and schedules more difficult than with traditional methods.
Inadequate or inappropriate architecture:
The architecture chosen during the early cycles may become inadequate as newer requirements become known.
Neglect of non-functional requirements:
A major concern with iterative RE in agile development is the inadequate attention given to non-functional requirements
Customer access and participation:
: The effectiveness of communication between the customer and team depends on several factors, including:
• customer availability;
• customer consensus; and
• customer trust, especially at the beginning of the project.
Several customers groups:
• The development team needs to spend extra effort to integrate the requirements of different segments through negotiation with each customer.
Trust:
• The establishment of trust between the customer and the developer can be very challenging in agile development.
Prioritization on a single dimension:
Inadequate requirements verification:
Minimal documentation:
How to use Requirement engieering
Off course both agile and plan-based approaches to RE must be tailored to the specific context.
For example, in the plan-based approach you need to decide how to document requirements, and in the agile approach you need to carefully consider which users to integrate in the team.
In both cases you need to integrate benefits realization (for example using BDN) into RE processes, to make sure that you actually work on the requirements that might support the creation of business benefits.
The two approaches to RE (plan-driven and agile) are related to the two different ways of using BDN’s: A plan-driven approach will be extremely difficult when working with innovation-based interventions.
Reflections and Relations
Relating benefits and requirements
It is clear that both plan-driven and agile approaches lacks a transparent and explicit linkage between the business benefits to be achieved and the requirements to IT systems. None of the approaches are benefits driven.
It is also clear that both approaches lacks transparency between the different factors in a BDN that together supports benefits delivery and value creation – it is not documented /discussed in the plan-driven or agile approaches how requirements to IT-enablers and requirements to Business changes somehow must be aligned. This is off course highly problematic.
