Lecture 2 - Requirement Engineering

Question 1

Define Requirements Engineering

Answer 1

An activity that starts with planning, which involves identifying the project goals, constraints, and stakeholders. This step is crucial as it sets the direction for the entire project. REFER TO SLIDES FOR EXAMPLES

Question 2

Why is Requirements Engineering difficult?

Answer 2

• SW Engineering is a creative, problem solving activity
• Real customers are not sure what they want
• Different stakeholders with different needs and priorities
• Real developers are not sure how to build it
• Real requirements creep

Question 3

Whats a way to make Requirements Engineering easier?

Answer 3

It is difficult to capture intent with only “words” So use some diagrams/pictures
Tip: PowerPoint is a fast & cheap way to mock-up a user interface. Can be 1/10 the time to do mock-ups in code.

Question 4

Why is Requirements Engineering important (or in other word what would happen if you didnt have proper requirements?

Answer 4

Poor requirements capture = Big problem (=$$)
Misunderstanding = Chaos (=$$)
= Software project failure (=$$$$$$$!)

Question 5

What are the 4 major activities of Requirements Engineering?

Answer 5

• Elicitation: discover the requirements
• Analysis: ensure the requirements are correct, complete, consistent and unambiguous
• Specification: document the requirements
• Validation: ensure that the system addresses the client’s needs

Question 6

What are Functional Requirements

Answer 6

An area of functionality the system must support.
- The functional requirements describe the interactions between the actors and the system independent of the realization of the system

Question 7

What are Non-functional Requirements

Answer 7

A user-visible constraint on the system (restriction or limitation).
- Non-functional requirements describe user-visible aspects of the system that are not directly related with the functionality of the system.

Question 8

What are some Quality Attributes of Non-functional Requirements?

Answer 8

Usability: How easy the system/service is to use
Reliability: Make sure the products works consistently
Security: Protecting the clients data, making product trustworthy
Safety: Make sure the product shouldn’t hurt anyone
Performance
Maintainability
Portability
Privacy

Question 9

What are Project Requirements?

Answer 9

Include: Business, Product and Process Requirements

Question 10

What are Business Requirements?

Answer 10

• Business Requirements describe in business terms what must be delivered or accomplished to provide value.

Question 11

What are Product Requirements?

Answer 11

• Product Requirements describe the system or product which is that will accomplish the business requirements.

Question 12

What are Process Requirements?

Answer 12

• Process Requirements describe the processes the developing organization must follow and the constraints that they must obey

Question 13

Sample Requirements Document Structure

Answer 13

REFER TO SLIDES

Question 14

What does Requirement Elicitation consist of?

Answer 14

Process: Identifying stakeholders, using techniques such as interviews, surveys and workshops
Essence: inclusive - functional and none-functional requirements
Communication: Actively listening to stakeholders needs - promoting alignment
Scope: Understanding the underlying problems, understanding what the stakeholder really wants and what it means to them

Question 15

What is the difference between requirements and specification?

Answer 15

“Requirements is probably the most misused word in our industry.”
“Required means non-negotiable, yet in almost every project we see changed, bartered, and negotiated requirements”
VS
“The term “specification” acknowledges that software development is an iterative and evolving process.”

Question 16

What is the Project Scope?

Answer 16

• A critical element of requirements elicitation is informing the project scope.
• Description of the software to be built and its purpose
• Prioritizing the deliverables to ensure the customer’s most important business needs
• how: time and other resources available to do this

Question 17

What are the challenges of Requirement Elicitation?

Answer 17

• Articulation Problems
  – People don’t know what they want so they can’t tell you about it!
• Communication Barriers
  – Different “languages” in different domains
• Knowledge and Cognitive Limitations
  – Managing complexity
• Human Behaviour Issues
  – Conflicting needs
• Technical Issues
  – Change management
  – Too rigid adherence to methodology

Question 18

What are the Requirement Sources?

Answer 18

• Goals
• Domain knowledge
• Stakeholders
• Business Rules
• Operational Environment
• Organisational environment

Question 19

What is Requirement Source: Goals?

Answer 19

• The high-level objectives of the software.
• Goals provide the motivation for the software but are often vaguely formulated.
• Software engineers need to pay particular attention to assessing the value (relative to priority) and cost of goals.
• A feasibility study is a relatively low-cost way of doing this.

Question 20

What is Requirement Source: Domain knowledge?

Answer 20

The unique ideas and knowledge in specific area, ie industry, business, etc
As well as the rules and regulations - regulatory and compliance requirements

Question 21

What is Requirement Source: Business Rules?

Answer 21

• These are statements that define or constrain some aspect of the structure or the behavior of the business itself.
• “A student cannot register in next semester’s courses if there remain some unpaid tuition fees” would be an example of a business rule for a university’s course-registration software.

Question 22

What is Requirement Source: Operational Environment?

Answer 22

• Requirements will be derived from the environment in which the software will be executed.
• These may be, for example, timing constraints in real-time software or performance constraints in a business environment.

Question 23

What is Requirement Source: Organizational Environment?

Answer 23

• Software is often required to support a business process, the selection of which may be conditioned by the structure, culture, and internal politics of the organization.

Question 24

What are the methods of Requirements Elicitation

Answer 24

1. Interviews
2. Facilitated meetings
3. Prototypes
4. Observation
   * Scenarios
   * User stories

Question 25

FOCUS: Interviews - Why are interviews good?

Answer 25

* Interviewing stakeholders is a “traditional” means of eliciting requirements.

Question 26

Define Interview

Answer 26

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

Question 27

How are interviews defined as successful?

Answer 27

* 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.

Question 28

What are the 5 steps of the interviewing process?

Answer 28

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

Question 29

FOCUS: Facilitated Meetings - What is it?

Answer 29

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

Question 30

What are the Advantages and Disadvantages of Facillicated meetings?

Answer 30

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)

Question 31

FOCUS: Prototypes - What is it?

Answer 31

* 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)

Question 32

What are the Disadvantages/Risks of Prototypes?

Answer 32

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

Question 33

What are Scenarios and Use Cases?

Answer 33

- 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.

Question 34

FOCUS: Observation - What is it?

Answer 34

* This helps discover implicit system requirements that reflect the actual tasks performed during the day rather than formal processes in which people are involved everyday.

Question 35

What are the Advantages and Disadvantages of Observations?

Answer 35

* 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

Question 36

What is a Generic Requirement Process?

Answer 36

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)

Question 37

What are the questions we ask as part of system thinking?

Answer 37

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?

Question 38

What are the 13 Elicitation Guidelines?

Answer 38

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