You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
61 lines
4.0 KiB
61 lines
4.0 KiB
1 year ago
|
We spent the first 5-10 minutes finalizing teams and projects
|
||
|
|
|
||
|
|
---------
|
||
|
|
|
||
|
|
Objectives for requirements elicitation:
|
||
|
|
1) Understand the problem
|
||
|
|
2) Understand how software is supposed to solve that problem
|
||
|
|
|
||
|
|
The aim of this stage is to write "User requirements": describe the problem domain (the program's external environment) and the effects that the software is required to have on it. Later on we will consider "System requirements" (which describe on a technical level how the solution interacts with its external environment). At this point you are learning about the problem domain, work activities, existing assets, and desired feaures so that the software's desired effects can be clearly defined.
|
||
|
|
|
||
|
|
Key tools:
|
||
|
|
1) Ask questions to aim discussion and to build your understanding
|
||
|
|
If you don't understand something important, better to ask now than to go back 2 weeks from now.
|
||
|
|
Have *some* prepared questions but ask others as needed
|
||
|
|
2) Observe current process/workflows
|
||
|
|
Seeing the way they do things now is very helpful to understanding the problem domain
|
||
|
|
3) Determine common usage scenarios / stories
|
||
|
|
4) Use active listening
|
||
|
|
Show interest and listen attentively, seeking to understand
|
||
|
|
Take lots of notes (have a note-taker on your team)
|
||
|
|
If you are unsure if their message got across cleanly, echo back your understanding of it
|
||
|
|
|
||
|
|
Example of active listening:
|
||
|
|
C: "After the IRB is done with their meetings, I upload their document to Cayuse."
|
||
|
|
D: "What is 'IRB'?" (clarifying domain-specific terminology)
|
||
|
|
C: "Internal Review Board - it's the group of people responsible for determining if the study meets ethical and legal requirements."
|
||
|
|
D: "And Cayuse, is that a software product?" (looking to understand current process)
|
||
|
|
C: "Yes, it's what we are using currently to manage all of the documents and where we are at in the process for each study, but it is somewhat limited and doesn't quite meet all of our needs."
|
||
|
|
D: [Makes a note to ask about those missing needs]
|
||
|
|
D: "So I imagine you have this fixed group of 3 or 4 people, whose job it is to make sure that each research study is legal and ethical. They meet however many times they see fit, and then they send you their final document and you upload it to Cayuse." (active listening)
|
||
|
|
C: "Yes, but it's not always the same group, and the number of people varies, depending on the study." (correcting misunderstanding)
|
||
|
|
D: "Got it. So tell me why Cayuse isn't meeting all of your needs." (follwing up on previous note)
|
||
|
|
|
||
|
|
Be careful that "active listening" doesn't become "parroting".
|
||
|
|
|
||
|
|
Some common difficulties in meeting with the customer:
|
||
|
|
* They might find the system hard to describe - people rarely have a complete idea of what they want up front.
|
||
|
|
* That's fine - just find out what they *do* have envisioned so far and build from there.
|
||
|
|
* They might use domain-specific vernacular or assume you already have domain-specific knowledge.
|
||
|
|
* Just ask them about it. You aren't expected to know everything.
|
||
|
|
* They may go on tangents
|
||
|
|
* Don't feed the tangent unless it's helpful. Bring the conversation back to core focus as soon as you reasonably can.
|
||
|
|
|
||
|
|
See examples of requirements documents. See also the template on pg 123.
|
||
|
|
|
||
|
|
A quick requirements elicitation checklist:
|
||
|
|
* Did you meet with all customers and stakeholders who should be involved at this point?
|
||
|
|
* Have you determined all user roles for the software?
|
||
|
|
* Have you walked through the most common usage scenarios for each user role?
|
||
|
|
* Is it clear what form/format inputs and outputs should take?
|
||
|
|
* Do you know what user interfaces will be provided, and on what platform(s) (web / mobile / pc)?
|
||
|
|
* Have you resolved any required interfaces to other hardware/software?
|
||
|
|
* Were time constraints for the project discussed?
|
||
|
|
* Do people agree about success criteria for the project?
|
||
|
|
|
||
|
|
We started a role play for requirements elicitation on the BFR project (we will finish that Friday).
|
||
|
|
|
||
|
|
Homework, due Friday:
|
||
|
|
Read 4.3.1 and 5.1-5.3 and correspond to set up initial meeting for next week.
|
||
|
|
Find any background info you can for your project and write some questions for the initial interview.
|