Lecture 2 - Requirement Engineering Flashcards

Question

FOCUS: Interviews - Why are interviews good?

Answer 1

* Interviewing stakeholders is a “traditional” means of eliciting requirements. * Important to understand the advantages and limitations of interviews and how they should be conducted.

Answer 2

* An interview is a systematic attempt to collect information from a person.

Answer 3

* Interviewing success depends on ability to identify: – work flows, – factors that influence the operations of systems, and – the elements (documents, procedures, policies, etc.) that make up systems.

Answer 4

1. Preparing for the interview 2. Planning and scheduling the interview 3. Opening and closing the interview 4. Conducting the interview 5. Following up for clarification

Answer 5

Try to achieve a summative effect, whereby a group of people can bring more insight into their software requirements than by working individually.

Answer 6

Advantage: * Brainstorm and refine ideas that may be difficult to bring to the surface using interviews. * conflicting requirements surface early on in a way that lets the stakeholders recognize where these occur. * may result in a richer and more consistent set of requirements than might otherwise be achievable. Disadvantage: * meetings need to be handled carefully (hence the need for a facilitator) to avoid poor group dynamics * Meetings are time consuming (hence the need for a facilitator)

Answer 7

* Valuable tool for clarifying ambiguous requirements. * Act in a similar way to scenarios by providing users with a context within which they can better understand what information they need to provide. * Wide range of prototyping techniques—from paper mockups of screen designs to beta-test versions of software products * Protypes can also be used requirements validation (see later) * Low fidelity prototypes are often preferred to avoid the stakeholder “anchoring” on minor, incidental characteristics that could limit design flexibility

Answer 8

* Disadvantage: Choose implementation too early * Risk: Rough prototype becomes the product

Answer 9

- Scenarios and use cases are commonly used in planned methodologies, especially in the object-oriented UML setting - Scenarios provide a valuable means for providing context to the elicitation of user requirements. - They allow the software engineer to provide a framework for questions about user tasks by permitting “what if” and “how is this done” questions to be asked.

Answer 10

* This helps discover implicit system requirements that reflect the actual rather than formal processes in which people are involved

Answer 11

* Advantage: discovers many user tasks and business processes that are too subtle and complex for their actors to describe easily. === * Disadvantage: Expensive (analyst works in client environment) * Disadvantage: Observer should be detached: end-user based, nonjudgemental so not appropriate for discovering organisational or domain requirements

Answer 12

ELICITATION * Identify relevant sources of requirements * Ask appropriate questions to gain an understanding of their needs AND THEN * Analyse the gathered information, looking for implications, inconsistencies or unresolved issues * Confirm your understanding of the requirements with the users (validate) * Synthesize appropriate statements of the requirements (specify)

Answer 13

1. What objectives are we trying to achieve? 2. What decisions do we control which affect those objectives? 3. What items dictate constraints on our range of choices? 4. What criteria should we use to evaluate candidate solutions? 5. What decision provides with the most satisfactory outcome with respect to those criteria?

Answer 14

1. Assess system feasibility 2. Be sensitive to organisational and political considerations 3. Identify and consult system stakeholders 4. Record Requirements Sources 5. Define the system’s operating environment 6. Use business concerns to drive requirements elicitation 7. Look for domain constraints 8. Record requirements rationale 9. Collect requirements from multiple viewpoints 10. Prototype poorly understood requirements 11. Use scenarios to elicit requirements 12. Define operational processes 13. Reuse requirements