Joint Application DevelopmentWikipedia says:Joint application design (JAD) is a process used in the prototyping life cycle area of the Dynamic Systems Development Method (DSDM) to collect business requirements while developing new information systems for a company. "The JAD process also includes approaches for enhancing user participation, expediting development, and improving the quality of specifications." 3
Requirements ElicitationWikipedia says:requirements elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders. 4
What is a User Story• A user story describes a small piece of system functionality, in a simple and easy to read sentence.• A well written user story will describe what the desired functionality is, who it is for, and why it is useful.• There are 3 parts to a fully fleshed out user story.• If you like marketing-speak, then you can call them the “3 C’s”: – The Card – The Conversation – The Confirmation
The Card • A typical user story follows one of these templates: – “As a [user], I want [function], so that [value]” – “As a [Noun], I want [Verb], so that [Business Goal]” • We refer to this as “The Card” because often they are written on 3x5 bits of plain card, usually to give a physical constraint which limits the possible length of the story.
An Example from the Real World:• Here’s a few hypothetical examples written for YouTube. I’ve defined a “Creator” as someone who contributes videos to the site, and “User” as someone who just watches them: • As a Creator, I want to upload a video so that any users can have access to my videos 24/7. • As a User, I want to search for videos by keywords so that I can find videos that are relevant to my search criteria.
The Conversation• Think of the conversation as an open dialogue between everyone working on the project, the clients, and or the Stakeholders. – Anyone can • Raise questions • Ask for things to be clarified – The answers should be recorded down as bullet points on the card for later reference – It is also a stage where you can reevaluate your user story – Possibly split it into multiple stories if required – This is not to be taken Personally
Conversation Example 1• For example, we discuss the creator upload user story, and decide that there are actually multiple things that can happen, so we split them, and expand on them: – As a Creator, I want to upload a video from my local machine so that any users can view it.• Examples of requirements from the User Story – The “Upload” button shall be a persistent item on every page of the site. – <BR> Videos must not be larger than 100MB, or more than 10 minutes long. – <BR> File formats must be .flv, .mov, .mp4, .avi, and .mpg. – Upload progress shall be shown in real time.
Conversation Example 2• As a Creator, I want to edit the video’s metadata while a video is uploading, to save myself time.• Examples of requirements from the User Story – The system shall have editable fields that include Video Name, description, tags, and privacy settings. – Once saved, the system shall take the user to their video’s dedicated page.
The Confirmation• The confirmation is basically just a test case. – A test case is a series of steps that a user must do to achieve the User Story. – A test plan is a collection of test cases. – With full coverage of your system in your test plans, you can easily test every core piece of functionality and tick them off as you go through them.
Confirmation Example• A test case for our YouTube example might look like this: – As a Creator, I want to upload a video from my local machine so that any users can view it. 1. Click the “Upload” button. 2. Specify a video file to upload. 1. Check that .flv, .mov, .mp4, .avi, and .mpg extensions are supported. 2. Check that other filetypes aren’t able to be uploaded. 3. Check that files larger than 100MB results in an error. 4. Check that movies longer than 10 mins result in an error. 3. Click “Upload Video”. 4. Check that progress is displayed in real time.
An Example from Our Real World: The Role: As a: Systems Administrator The Action: I want to: configure the message that will be displayed when posting attendance is restricted by Last earned date The Goal/Benefit Achieved by the Action: So that…(Benefit): Instructors/Registrar can be alerted as to which faculty member/department needs to be notified when attendance posting may be rejected if they attempt to post attendance for a date that is prior to the day after the last earned date, instead of a generic message.
How do I know I’ve Met my Goal/Benefit?As the customer, how will I be able to test / or accept that thefeature goal / benefit has been met? The Confirmation: Log in as system administrator and turn on the option that attendance cannot be posted before or equal to last earned date. Configure a message to be seen if an instructor/registrar attempts to post attendance prior to or equal to the last earned date Log in as instructor/registrar Attempt to enter attendance for a date prior to or equal to last earned date The message that was configured should be displayed. 15
Requirements Elicitation to include Non-FunctionalRequirements 16
Invest in your User StoryIt stands for all the things a good user story should be: I • Independent N • Negotiable V • Valuable E • Estimable S • Small T • Testable