lecture 7: requirement analysis

Question 1

Benefits dependency network (BDN)

Answer 1

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.

Question 2

Problem-based interventions

Answer 2

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

Question 3

Innovation-based intervention

Answer 3

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

Question 4

Requirements engineering (RE)

Answer 4

The broad spectrum of task and techniques that lead to an understanding of requirements (to IT systems).

Question 5

Functional requirement

Answer 5

the calculation, information etc that the system has to deliver.

Question 6

non-functional requirements

Answer 6

security, usability, performance etc.

Question 7

investments

Answer 7

ends –> target improvements (10% improved profit etc)

ways and means –> the need of business changes and IT capabilities (better ways of working, BI etc)

Question 8

the essence of the requirement analysis

Answer 8

before defining the requirements it important to define the benefits that the IT solution and business changes are going to deliver

Question 9

Framework: BDN network

Answer 9

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

Question 10

what to take with from the BDN diagrams

Answer 10

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.

Question 11

Classic requirement engineering

Answer 11

Trying to complete the requirements before movnig along in the project (look at lecture 2 about SDCL plan-driven method)

Question 12

Classic requirement engineering basic activities: inception

Answer 12

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

Question 13

Classic requirement engineering basic activities: Elicitation

Answer 13

elicit requirements from all stakeholder

Question 14

Classic requirement engineering basic activities: Elaboration

Answer 14

Create an analysis model that indentifies data, function and behavior requirements.

Question 15

Classic requirement engineering basic activities: Negotiation

Answer 15

agere on a deliverable system that is realistic for developers and customers

Question 16

Classic requirement engineering basic activities: specification

Answer 16

can be one or more of the following: written document, a set of models, formal mathematical model, collection of user scenarios(use-cases), prototyping

Question 17

Classic requirement engineering basic activities: validation

Answer 17

review mechanism that looks for; errors, areas where clarification is required, missing informations, inconsistencies, conflicting or unrealistic requirements

Question 18

Classic requirement engineering basic activities: requirement management

Answer 18

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.

Question 19

Agile requirement engineering

Answer 19

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

Question 20

Agile requirement engineering preferences:

Answer 20

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.

Question 21

agile challenges: cost and schedule estimation

Answer 21

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.

Question 22

agile challenges: bad architecture

Answer 22

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.

Question 23

agile challenges: several customer groups

Question 24

agile challenges: trust

Answer 24

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.

Question 25

agile vs. traditional requirement engineering: elicitation

Answer 25

Traditional: Disvoering all the requirements upfront
agile: requirements evolve over time and are discovered throughout the development process.

Question 26

agile vs. traditional requirement engineering: analysis and negotiation

Answer 26

traditional: focus in resolving conflicts
agile: focus on refining, changing and prioritizing requirements iteratively

Question 27

agile vs. traditional requirement engineering: documentation

Answer 27

traditional: formal documentation containing detailed requirements
agile: no formal documentation

Question 28

agile vs. traditional requirement engineering: Validation

Answer 28

traditional: the consistency and completeness of requirements document
agile: focus in ascertaining whether the requirements reflect current user needs