Elicitation Notes - Edge-Locksmith-Services/Locksmith-website GitHub Wiki
- Interview- “Traditional” mean of eliciting requirements. One on one meeting. Should have questions prepared to be asked.
- Survey or Questionnaire-
- Scenarios- Allow the software engineer to provide a framework for questions about user tasks by asking “what if” and “how is this done”. Most common type of scenario is the use case description.
- Prototypes- A valuable tool for clarifying ambiguous requirements. Can act is a similar way to scenarios by providing users context within which they can better understand what information you need to provide. There multiple different types of prototyping techniques such as wireframe, Mockup, and prototype.
- Facilitated Meetings- Held together with a group of people can bring more insight into the requirements than working individually. Can brainstorm and refine ideas that may not not come up during interviews. Conflicting requirements may be found by stakeholders and rectified. Meeting need to be handled carefully.
- Observation- Learn about the user tasks by immersing themselves in the environment and observing how users perform their tasks by interacting with each other and with software tools and other resources.
- User Stories- The technique is commonly used in adaptive methods such as Agile and refers to short, high level descriptions of required functionality expressed in customer terms. A typical user story has the form: “As a , I want <goal/desire> so that .”
- Other Techniques- A range of other techniques for supporting the elicitation of requirements information exist and range from analyzing competitors’ products to applying data mining techniques to using sources of domain knowledge or customer request databases.
Examples of Stakeholders
Typical examples of software stakeholders include (but are not restricted to) the following:
- Users: This group comprises those who will operate the software. It is often a heterogeneous group involving people with different roles and requirements.
- Customers: This group comprises those who have commissioned the software or who represent the software’s target market.
- Market analysts: A mass-market product will not have a commissioning customer, so marketing people are often needed to establish what the market needs and to act as proxy customers.
- Regulators: Many application domains, such as banking and public transport, are regulated. Software in these domains must comply with the requirements of the regulatory authorities.
- Software engineers: These individuals have a legitimate interest in profiting from developing the software by, for example, reusing components in or from other products. If, in this scenario, a customer of a particular product has specific requirements that compromise the potential for component reuse, the software engineers must carefully weigh their own stake against those of the customer. Specific requirements, particularly constraints, may have major impact on project cost or delivery because they either fit well or poorly with the skill set of the engineers. Important tradeoffs among such requirements should be identified
Start by brainstorming who your stakeholders are.
- Your boss
- Senior executives
- Alliance partners
- Trades associations
- Your co-workers
- The press
- Your team
- Interest groups
- The public
- Prospective customers
- Future recruits
- The community
- Your family
- Key contributors
- Key advisors
- Goals- Why the business wants to make the software and what they hope to achieve with the software.
- Domain Knowledge- The software engineer needs to acquire or have knowledge about the application domain. Provides the background against which all elicited requirements knowledge must be set in order to understand it.
- Stakeholder- The software engineer needs to identify, represent, and manage the “viewpoints” of many different types of stakeholders.
- Business rules- Statements that define or constrain some aspect of the structure or the behavior of the business itself.
- Operational Environment- The requirements will be derived from the environment that the software will be executed.
- Organizational Environment- Software should not force unplanned changes on the established business process.