Requirements Elicitation Techniques

• Overview of requirements elicitation
• Requirements elicitation techniques
• Use cases

• A collaborative and analytical process that includes activities to collect, discover, extract, and define requirements
• Discovers business, user, functional, and non-functional requirements
• Engaging users in the elicitation process is a key element for success

• Determine sources of requirements and select appropriate techniques
• Elicit information on domain, problem, needs, and constraints
• Produce a first document
  • Mainly user requirements and elicitation notes
  • Potentially incomplete and inconsistent but one must start somewhere

• May be one-on-one or small group interviews
• Strengths:
  • Effective for getting to know the application domain quickly
  • Interviewees may be more comfortable sharing their thoughts than in a workshop setting
  • Easier to establish user involvement
  • Suitable for busy executives

• A representative group of users who convene in a facilitated elicitation activity to generate input and ideas on a product’s functional and quality requirements U
• seful for exploring users’ attitudes, impressions, preferences, and needs

You will need to keep them on topic without influencing their opinions Include users who have used previous versions or similar products Select users from different user classes or a bunch of users from the same class and hold several focused groups

-making authority for requirements

Participants in focus groups normally don’t have decision

• Strengths:
  • Suitable for building a new version of an existing system
  • Facilitates identification of areas of improvement
  • Relates user input to reality, thereby clarifying it

• A scenario is a description of a single instance of a usage of a system
• A use case is a collection of related usage scenarios, and a scenario is a specific instance of a use case
  • Specific actor, at a specific time, with specific data Scenario 1: Request a chemical from the checmical stockroom Request a Chemical Scenario 2: Request a checmical from a vendor

• Narrative form – a paragraph focusing on the primary scenario and some secondary ones A User inserts a card in the card reader slot. The system asks for a personal identification number (PIN). The user enters a PIN. After checking that the user identification is valid, the system asks the user to chose an operation...
• Useful when stakeholders first meet

• Strengths:
  • Users have clearer expectations of what the system will do
  • BA’s and developers better understand user’s business
  • Prevents implementation of unneeded functionality
  • May be turned into object models for object-oriented design
• Risks:
  • Too many use cases
  • Highly complex use cases

• A negative scenario is one with a goal that is:
  • Undesirable from a business obejctive’s perspective D esriable from a hostile agent’s perspective
• Can be handled using misuse cases
  • Proposed by Sindre & Opdahl (2000)
  • Capture use cases that a system must be protected against
  • Obvious applications for security and risk analysis

• Strengths:
  • Useful for eliciting security anf safety requirements
  • Early identification of threats, mitigations, and exceptions
• Risks:
  • If used during elicitation, it could lead to premature design solutions when identifying mitigations
  • Potential for missing misactors or threats if consulting partial view of system

M. Zarour, M. Alenezi: Software Security Specifications and Design How Software Engineers and Practitioners Are Mixing Things up

• Prototypes can serve three major purposes, and that purpose must be made clear from the very beginning:
  • Clarify, complete, and validate requirements – requirements tool
  • Explore design alternatives – design tool
  • Create a subset that will grow into the ultimate product – construction tool

Rapid Prototyping: Digital Figma

Include them in project plans State the purpose of each prototype before you build it Plan to develop multiple prototypes Create throwaways as quickly and cheaply as possible Don’t prototype requirements that you already understand, except to explore design alternatives Don’t expect a prototype to replace written requirements

Factors to consider when choosing elicitation techniques:

• The nature of the information being elicited in terms of consciousness
• The time and budget constraints
• The availability of stakeholders
• The experience of the BA with a particular elicitation technique

• Functional requirements
  • What will the system do?
  • When will the system do it?
  • Are there several modes of operations?
  • What kinds of computations or data transformations must be performed?
  • What are the appropriate reactions to possible stimuli?
  • For both input and output, what should be the format of the data?
  • Must any data be retained for any period of time?

• Design Constraints
  • Physical environment
    • Where is the equipment to be located?
    • Is there one location or several?
    • Are there any environmental restrictions, such as temperature, humidity, or magnetic interference?
    • Are there any constraints on the size of the system?
    • Are there any constraints on power, heating, or air conditioning?
    • Are there constraints on the programming language because of existing software components?

• Design Constraints
  • Interfaces
    • Is input coming from one or more other systems?
    • Is output going to one or more other systems?
    • Is there a prescribed way in which input/output need to be formatted?
    • Is there a prescribed way for storing data?
    • Is there a prescribed medium that the data must use?
  • Standards
    • Are there any standards relevant to the system?
  • Laws, policies, and regulations
    • Are there any laws, policies, or regulations applicable here?

• Performance
  • Are there constraints on execution speed, response time, or throughput?
  • What efficiency measure will apply to resource usage and response time?
  • How much data will flow through the system?
  • How often will data be received or sent?
• Usability and Human Factors
  • What kind of training will be required for each type of user?
  • How easy should it be for a user to understand and use the system?
  • How difficult should it be for a user to misuse the system?

• Security
  • Must access to the system or information be controlled?
  • Should each user's data be isolated from data of other users?
  • Should user programs be isolated from other programs and from the operating system?
  • Should precautions be taken against theft or vandalism?

• Reliability and Availability
  • Must the system detect and isolate faults?
  • What is the prescribed mean time between failures?
  • Is there a maximum time allowed for restarting the system after failure?
  • How often will the system be backed up?
  • Must backup copies be stored at a different location?
  • Should precautions be taken against fire or water damage?

• Maintainability
  • Will maintenance merely correct errors, or will it also include improving the system?
  • When and in what ways might the system be changed in the future?
  • How easy should it be to add features to the system?
  • How easy should it be to port the system from one platform (computer, operating system) to another?
• Precision and Accuracy
  • How accurate must data calculations be?
  • To what degree of precision must calculations be made?

• https://medium.theuxblog.com/11-best-prototyping-tools-for-ui-ux-designers-how-to-choose-the-right-one-c5dc69720c47
• https://www.justinmind.com