lecture 7: requirement analysis 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.
Problem-based interventions
ends-driven because the goal is the target improvements.
Definition: Has a clear target, hard agreeing on the best combinations of ways and means, clear benefits
Innovation-based intervention
ways and means-driven because the goal is to discover better ways of working by utilizing IT (the means) or new ways of e.g. organizing (the ways).
Definition: unclear target, unclear benefits, require creativity and changes, require on-going learning
!! Issue: to much attetion to what the technology can do and not what changes the organization needs to make to exploit the technology
Requirements engineering (RE)
The broad spectrum of task and techniques that lead to an understanding of requirements (to IT systems).
Functional requirement
the calculation, information etc that the system has to deliver.
non-functional requirements
security, usability, performance etc.
investments
ends –> target improvements (10% improved profit etc)
ways and means –> the need of business changes and IT capabilities (better ways of working, BI etc)
the essence of the requirement analysis
before defining the requirements it important to define the benefits that the IT solution and business changes are going to deliver
Framework: BDN network
Linking the investment objective and requirement benefits (ends) with the business changes (the ways) that are necessary to deliver those benefits and the essential IT capabilities (the means) that enables these changes
what to take with from the BDN diagrams
the BDN digram is not the most important outcome, the thing to take from this is the shared understanding and commitment between you, IT mamagement and business management - about what the investment is going to achieve AND how it is going to be achieved.
Classic requirement engineering
Trying to complete the requirements before movnig along in the project (look at lecture 2 about SDCL plan-driven method)
Classic requirement engineering basic activities: inception
Ask the management a set of questions to establish; basic understanding of the problem, the people who want a solution, the nature of the solution that is desired and the effectiveness of preliminary communication and colloboration between the customer and the developer
Classic requirement engineering basic activities: Elicitation
elicit requirements from all stakeholder
Classic requirement engineering basic activities: Elaboration
Create an analysis model that indentifies data, function and behavior requirements.
Classic requirement engineering basic activities: Negotiation
agere on a deliverable system that is realistic for developers and customers
Classic requirement engineering basic activities: specification
can be one or more of the following: written document, a set of models, formal mathematical model, collection of user scenarios(use-cases), prototyping
Classic requirement engineering basic activities: validation
review mechanism that looks for; errors, areas where clarification is required, missing informations, inconsistencies, conflicting or unrealistic requirements
Classic requirement engineering basic activities: requirement management
managing all changes to the requirements, maintaining the relationship Amin the requirements, the project plans and the products (AND benefits). indentifying the inconsistencies among the requirements, the project plan and the work products.
Agile requirement engineering
The rapid changes are challenge the classical way of requirement engineering, and thats why agile RE could be a good choice.
In agile development, requirements are not pre-defined; instead they emerge during the development process. –> iterative RE
Requirement evolves –> therefor agile dev. Not spend much time on inital requirments elicitation.
Documentation –> does not document requirements in detail upfront
Interaction –> able for customers to frequent interact with developers
Cost-of-change –> cost of making change does not dramatically change over time
Agile requirement engineering preferences:
Agile software prefers face-to-face communication - this is important to remember!!!
This is IF The customer are collaborative, representative, available, capable and knowledgeable to provide the right requirements to the development team.
agile challenges: cost and schedule estimation
it is more difficult to make the right estimations about cost and schedules with the agile approach than with the traditional approach
so even though agile dev. helps create better cost/schedule estimates for individual dev. cycles, the on going change of the scope of the project makes it difficult to make the right estimate for the entire project.
agile challenges: bad architecture
the architecture that is chosen early on in the project might not be the right fit as newer requirements become known. therefor rework of the architecture may add significant cost to the project.
agile challenges: several customer groups
agile challenges: trust
it is important to establish trust between the customer and the developer. the agile method can create mistrust because the lack of detailed requirements or design specifications.
agile vs. traditional requirement engineering: elicitation
Traditional: Disvoering all the requirements upfront
agile: requirements evolve over time and are discovered throughout the development process.
agile vs. traditional requirement engineering: analysis and negotiation
traditional: focus in resolving conflicts
agile: focus on refining, changing and prioritizing requirements iteratively
agile vs. traditional requirement engineering: documentation
traditional: formal documentation containing detailed requirements
agile: no formal documentation
agile vs. traditional requirement engineering: Validation
traditional: the consistency and completeness of requirements document
agile: focus in ascertaining whether the requirements reflect current user needs
