• Author / Uploaded
• Shephali Dheeraj Tyagi

• Categories
• Desarrollo de prototipo de Software
• Cuestionario
• Caso de uso
• Desarrollo de software
• Proceso de desarrollo de software

Citation preview

1

Requirements Determination – Part 1

Elicitation, analysis and negotiating customer requirements

2

Requirements Determination ●

Requirements determination is the least technical but the most critical phase of the software development lifecycle –

●

requires good social, communication and management skills

The focus is on determining the stakeholder's requirements –

service statements –

–

functional requirements: what the system does, its functionality, data structures

constraint statements –

non-functional requirements: how well the system provides the functional requirements ●

usability, reusability, reliability, performance, efficiency, supportability

3

Requirements – Examples ●

●

Functional requirements –

the system should provide budget reports

–

the user can select which pages to print

Non-functional requirements –

operational constraints ●

–

performance constraints ●

–

the system should be able to work on any Web browser any interaction between the user and the system should not exceed 2 seconds

security constraints ●

only direct managers can see personnel records of staff

4

The Requirements Determination Process ●

Requirements elicitation –

●

obtaining requirements from customers

Requirements reviews and renegotiations –

analyse requirements to eliminate duplication or contradictions

●

Classification and prioritisation

●

Business modelling –

system scope model, business use case model, business class model

●

Requirements document

●

Requirements management –

estimate the impact of a change on other requirements

5

Requirements Elicitation (1)

Domain Expert

Domain Knowledge Requirements

Customer

Business Analyst

Use Case Requirements

Business Model

Business Class Model

Business Use Case Model

6

Requirements Elicitation (2) ●

Traditional methods of requirements elicitation –

●

Modern methods of requirements elicitation –

●

prototyping, brainstorming, JAD, RAD

High risk projects –

●

interviewing customers and domain experts, questionnaires, observation, study of documents and software systems

unclear objectives, undocumented procedures, unstable requirements, eroded user expertise, inexperienced developers, insufficient user commitment

Traditional techniques are usually used in low-risk projects, while modern techniques are usually used in high-risk projects

7

Requirements Elicitation: Interviews (1) ●

The target: customers and domain experts –

●

use case requirements v. knowledge transfer

Difficulties with customers –

may only have a vague picture of their requirements

–

may be unwilling to cooperate

–

may be unable to express their requirements in understandable terms

–

may demand requirements that exceed the project budget

–

the requirements of different customers may be in conflict

8

Requirements Elicitation: Interviews (2) ●

Two kinds of interview –

●

Different kinds of questions –

●

structured, unstructured open-ended, closed-ended, probing

Advice –

ensure that people at different levels of the organisation are interviewed

–

provide a starting point and context for the discussion

–

send a memo summarising the interview to the interviewee after the meeting

–

good communication and interpersonal skills help

9

Requirements Elicitation: Interviews (3) ●

●

The following categories of questions should be asked –

questions about specific details

–

questions about a vision for the future

–

questions about alternative ideas

–

questions about a minimally acceptable solution

–

questions about other sources of information

–

questions soliciting diagrams

Three kinds of questions which should be avoided –

opinionated questions

–

biased questions

–

imposing questions

10

Requirements Elicitation: Interviews (4) ●

Advantages –

provides high quality information

–

can probe in greater depth

–

if the interviewee has nothing to say, the interview can be terminated

●

Disadvantages –

time-consuming

–

the analyst must work to obtain results after the interview

–

the interviewer may be biased

–

conflicting information from interviewees may be difficult to resolve

11

Requirements Elicitation: Questionnaires (1) ●

●

●

Questionnaires are an efficient way of gathering information and are normally used in addition to interviews Questionnaires are passive –

respondent has time to consider their response

–

respondent cannot clarify the question

Closed-ended questions are emphasised –

●

multiple-choice, rating questions, ranking questions

Advice –

a well-designed, easy-to-answer questionnaire gets a higher response rate

–

need to consider distortions when evaluating the results

12

Requirements Elicitation: Questionnaires (2) ●

Advantages –

–

economical way of gathering data from large numbers of people in well-designed questionnaires, results are easy to analyse

●

Disadvantages –

good questionnaires can be difficult to construct

–

it is difficult to follow up

–

may suffer from low response rates

13

Requirements Elicitation: Observation (1) ●

A business analyst may find it difficult to obtain complete information through interviews and questionnaires –

●

Three forms of observation –

●

observation may be an effective fact-finding technique passive observation, active observation, explanatory observation

Advice –

observations should be carried out for a prolonged period of time, at different time intervals, and at different workloads

–

be aware that people behave differently when observed

14

Requirements Elicitation: Observation (2) ●

Advantages –

– –

–

provides first hand experience of the way people work data collected can have a high level of validity can be used to verify information or to examine exceptional procedures can provide data about the performance of the existing system and users

●

Disadvantages –

people do not like being observed

–

requires a trained and skilled observer

–

has serious logistical problems for the analyst

–

there may be ethical problems

15

Requirements Elicitation: Studying Documents and Software Systems (1) ●

●

Useful for discovering both use case and domain knowledge requirements Potential sources of information –

organisation documents ●

–

business forms, work procedures, job descriptions, policy manuals, business plans, organisational charts, correspondence, minutes, accounting records, external correspondence, customer complaints

system forms and reports ●

computer screens and reports, system operating manuals, user and technical documentation, system analysis and design models

–

business domain journals and reference books

–

software packages

16

Requirements Elicitation: Studying Documents and Software Systems (2) ●

Is it worth studying legacy systems? –

if some of the functionality is required in the new system

–

if some of the data must be migrated into the new system

–

if the documentation provides algorithms that might be needed in the new system

–

to make sure any defects are avoided in the new system

–

may help to understand the organisation

–

if parts of the existing system may be retained

–

baseline information can be used to evaluate the new system's performance

17

Requirements Elicitation: Studying Documents and Software Systems (3) ●

Advantages –

helps in understanding the organisation

–

helps in preparing other kinds of fact finding

–

the existing system may provide formally defined requirements for the new system

●

Disadvantages –

written documents often do not match up to reality ●

out of date, differences between policy and practice

18

Requirements Elicitation: Prototyping (1) ●

●

Effective for eliciting requirements that are difficult to obtain from customers (especially concerning new systems) The most frequently used method of modern requirements elicitation –

software prototypes are constructed to visualise parts of the system

–

a “quick and dirty” working model of the solution ●

●

contains a GUI, and simulates the system behaviour

Two kinds of prototype –

throw-away prototyping, evolutionary prototyping

19

Requirements Elicitation: Prototyping (2) ●

Advantages –

helps to assess the feasibility and usefulness of a system

–

–

●

Disadvantages –

useful for clarifying requirements and resolving conflicts

user may find it difficult to realise the complexity of the project

–

quick and dirty solutions may end up in the final product

may speed up delivery

–

too much emphasis may be placed on the user interface

20

Requirements Elicitation: Brainstorming (1) ●

Brainstorming is a technique for forming new ideas or for finding a solution to a specific problem –

●

used because of the difficulty in reaching a consensus among stakeholders about the requirements

Consists of –

a facilitator ●

–

defines a “probortunity statement” consisting of trigger questions

12-20 people in a circle ●

think of answers to trigger questions

●

read out ideas

●

vote to prioritise the ideas

21

Requirements Elicitation: Brainstorming (2) ●

Examples of trigger questions –

what features should be supported by the system?

–

what are the input data and outputs?

–

what classes are needed in the business/domain object model?

–

what questions should be raised in interviews/questionnaires?

–

what issues need to be considered?

–

what are the main risks?

–

what trigger questions should be asked during this or future sessions?

22

Requirements Elicitation: JAD (1) ●

●

Joint Application Development (JAD) –

one or more workshops that bring together all stakeholders

–

a workshop can take a few hours to a couple of weeks

Participants (should not exceed 30) –

leader ●

–

conducts and moderates the meeting, is not a stakeholder

scribe ●

records the session, must have touch-typing skills

–

customers (users and managers)

–

developers ●

listen rather than speak

23

Requirements Elicitation: JAD (2) ●

Advantages –

group synergy is likely to produce better solutions to problems ●

groups increase productivity, learn faster, make more educated judgements, eliminate more errors, take riskier decisions, focus attention on the most important issues, etc.

●

Disadvantages –

problems during the sessions may be difficult to deal with ●

–

domination, noncontributors, side discussions, agenda merrygo-round, unresolved conflicts, etc.

design by committee can be bad

24

Requirements Elicitation: RAD (1) ●

An approach to software development emphasising speed of delivery over technical excellence –

●

attractive for smaller projects

RAD combines –

evolutionary prototyping

–

CASE tools with code generation

–

specialists with advanced tools (SWAT)

–

interactive JAD ●

–

replace the scribe with the SWAT team

timeboxing ●

forbids “scope creep” by trimming down the solution

25

Requirements Elicitation: RAD (2) ●

Advantages –

good for smaller projects

–

provides fast solutions

●

Disadvantages –

fast solutions are unlikely to be optimal or sustainable

–

problems ● ●

● ●

inconsistent GUI designs specialised rather than generic solutions deficient documentation software that is difficult to scale up

26

Requirements Elicitation Planning (1) ●

Identify the stakeholders

●

Evaluate the risk of the project

●

●

Select the most appropriate requirements elicitation techniques for each stakeholder and the project as a whole Consider the implementation details for each selected technique –

e.g. select people to interview, identify questions for interviews and questionnaires, decide how many interviews or questionnaires, organise JAD session, etc.

27

Requirements Elicitation Planning (2) ●

Criteria for selecting the most appropriate techniques (1) –

analyst's experience ●

–

type of information ●

–

studying business documents requires little experience while participating in a JAD session requires a lot understanding the current system, identifying improvements, developing the new system

depth of information ● ●

how rich and detailed is the information produced? to what extent is the technique useful for obtaining and understanding facts and opinions?

28

Requirements Elicitation Planning (3) ●

Criteria for selecting the most appropriate techniques (2) –

breadth of information ●

–

integration of information ●

–

how easy is it to combine information from different sources and resolve differences in opinion or facts

user involvement ●

–

the range of information and information sources that can be collected using a technique

how much time and energy do the intended users devote to the analysis process?

cost ●

low cost or high cost?

29

Requirements Elicitation Planning (4) ●

Requirements elicitation combines different techniques

●

Example –

to gain an understanding of the project and “big picture” ●

–

to understand the existing system ●

–

analyse documents, interviews

to identify improvements ●

–

interviews with senior manager(s)

JAD sessions, questionnaires

to understand the new system requirements ●

interviews with senior managers, JAD sessions for users at all levels