Chapter 4 – Requirements Engineering

1. Chapter 4 – Requirements Engineering • Lecture 3 Chapter 4 Requirements engineering 1

2. Practice: The Requirements Specification using Features, User Stories, Use Cases, Acceptance Criteria, and more The notes that follow are from emails, Google, etc, modified…. In my opinion, the book, while quite good in spots, does not provide enough information to support application development from a practical standpoint at this juncture in the book. Two primary mechanisms (certainly not the only ones) critical to software development requirements capture nowadays used to capture requirements are use cases (lectures coming) and features / user stories. Depending on your ‘take’ on these, a couple of these are similar. Yet they support different approaches to elicitation / capture of stakeholder requirements. Chapter 4 Requirements engineering 2

3. Features • Example of a Feature provided by a customer: • We need the system to handle multiple allocation requests • Can see this is very cryptic, but meaningful to a customer. • Does not, however, provide us much detail about the functional requirements really needed in sufficient detail to support design and development. • Yet, this is very meaningful to the customer. • One approach is to ask the customer a number of questions, such as why he needs this; hopefully, this will lead to a user story. If not, it will certainly help us to understand more of what this feature is all about.

4. Move from Features to User Stories • Consider a dialog: • Developer: Why do we need the system to handle multiple allocation requests?Customer: Because some orders will need to be split up. • Developer: And why do they need to be split up?Customer: Because not everything will fit onto one pallet. • Developer: Why won’t it all fit? Customer: Because we can only put so many of an item onto a single pallet. There’s just only so much room available to stack stuff safely. • Developer: So why does that affect the system?Customer: Because we don’t want customers to have to think about pallet splitting. We just want them to be able to place the order, and the system figure out how many pallets it needs to go onto. • We can see from that exchange that we learned a lot more about the system than we initially had: • (later in this chapter we will address interviews, questionnaires, etc.)

5. Move from Features to User Stories • Consider: We now know: • Pallets have an upper bound of how many items can fit onto it • The system should know how much of an item a pallet can hold • Customers will order more than one pallet’s worth of stuff in a single order • We’ll have to ship multiple pallets • We’ll have to track multiple pallets • We may have to handle returning multiple pallets of items • Multiple pallets should still be considered a single order • It isn’t clear if we can mix different items from the same order onto a pallet • We can then begin to turn these insights into user stories which capture what we need. • Oftentimes, the user provides user stories, which may be quite short, often incomplete, and some are long and do provide more detail…

6. Move from Features to User Stories • A second question often asked is: Given – When – Then • Consider: This basically says that given some preconditions, when an action happens in the system, thenpostconditions should be met. Applying this to our original feature, we have: • Developer: Ok, so you’ve said that the system should handle multiple allocations. At what point should it be able to handle those?Customer: Well, when the customer places the order  • Developer: Ok, so When the customer places an order…what should happen?Customer: Well, it’s not just any order. When a customer places an order that doesn’t fit on a single pallet.  • Developer: Ok, so Given we know how much can fit on a pallet, and Given that the customer has placed an order which is larger than a single pallet can handle, When they place an order, what should happen?  • Customer: Well, the order should be split up among multiple palletsDeveloper: Ok, and should those be treated as the same order, or should they be shipped as separate ones?  • Customer: No, no, they need to all go out and be tracked as one order

7. Move from Features to User Stories • We can then continue to create scenarios around the various things that will come up about the system. • What about orders with different item types? • What about orders which don’t fill up a pallet fully? • What about returns? • Class question: What do you infer a scenario is? • We can use the Given-When-Then syntax to come up with each of those. • Point: you cannot design a solution to requirements you do not understand.

8. User Stories (Wiki) • In software development and product management, a user story • is one or more sentences • in the everyday or business language of the end user or user of a system.. that captures what a user does or needs to do as part of his/her job function. • User stories: • used with agilesoftware development methodologies • form the basis for defining the functions a business system must provide, • and facilitate requirements management. • UserStories capture the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limitedindetail by what can be hand-written on a small paper notecard. • User stories: • written by or for the business user • is user's primary way to influencefunctionality of the system being developed. • User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.), though primarily it is the task of a product manager to ensure user stories are captured.

9. User Stories and Acceptance Tests • User stories are a quick way of handling customerrequirements without having to create formalizedrequirementdocuments and without performing administrativetasks related to maintaining them. • Intention of the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements. • A user story is an informal statement of the requirement as long as the correspondence of acceptance testing procedures is lacking. • Before a user story is to be implemented, an appropriate acceptance procedure must be ideally written by the customer to ensure by testing or otherwise whether the goals of the user story have been fulfilled. • Some formalization finally happens when the developer accepts the user story and the acceptance procedure as a work specific order.

10. Creating User Stories • How do we do this? • Developers gets together with a customer representative. • The customer is responsible for formulating the user stories. • The developermay use a series of questions (as we saw) to get the customer going, such as asking if some particular functionality is desired, but must be careful not to dominate the idea creation process. • Personal note: Difficult to get customers to say all they know. They are too close to the action and ‘assume’ many things are transparent or obvious. Always make sure you understand as much as possible. • Documentation of User Stories: typically written down on a card or sticky with a name and a description which the customer has formulated. (See Internet for tons of looosy goosy examples. Not formalized.) • If the developer and customer find that the user story is lacking in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory • Requirements tend to change during the development period, which is handled by not carving them in stone.

11. Creating User Stories • Commonly used templates follows: (See Wiki for credits) • "As a <role>, I want <goal/desire> so that <benefit>" • "As a <role>, I want <goal/desire>" • "In order to <receive benefit> as a <role>, I want <goal/desire>" • "As <who> <when> <where>, I <what> because <why>." • The <what> portion of the user story should be started with "need" or "want" to • differentiate between stories • that must be fulfilled for proper software operation • versus stories that • improvetheoperation, but are not critical for correct behavior.

12. User Stories - Examples • I want to modify my own schedules but not the schedules of other users. • As a mobile application tester, I want to test my test cases and report results to my management. • Starting Application • The applicationbegins by bringing up the last document the user was working with. • As a user closing the application, I want to be prompted to save if I have made any change in my data since the last save. • ClosingApplication • Upon closing the application, the user is prompted to save (when ANYTHING has changed in data since the last save!).

13. User Stories - Another Example • As a user closing the application, • I want to be prompted to save anything that has changed since the last save so that I can preserve useful work and discard erroneous work. • The consultant will enter expenses on an expense form. • The consultant will enter items on the form like expense type, description, amount, and any comments regarding the expense. • At any time the consultant can do any of the following options: • (1) When the consultant has finished entering the expense, • the consultant will “Submit”. If the expense is under fifty • (<50), • the expense will go directly to the system for processes. • (2) In the event the consultant has not finished entering the • expense, the consultant may want to “Save for later”. The • entered data should then be displayed on a list (queue) for • the consultant with the status of “Incomplete”. • (3) In the event the consultant decides to clear the data and • close the form, the consultant will “Cancel and exit”. The • entered data will not be saved anywhere. • Clearly these are much longer and provide much needed data.

14. User Stories - Usage • As a central part of many agile development methodologies, user stories define what has to be built in the software project. • User stories are • prioritizedbythecustomer to indicate most important needs and • will be broken down in tasks and estimated by the developers. • When user stories are about to be implemented the developers should have the possibility to talk to the customer about it. • The short stories may be • difficult to interpret, • may require some background knowledge or the • requirements may have changed since the story was written. • Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to validate it.

15. User Stories - Benefits • XP and other agile methodologies favor face-to-face communication over comprehensive documentation and quick adaptation to change instead of fixation on the problem. • User stories achieve this by: • Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks. • Allowing developer and the client representative to discuss requirements throughout the project lifetime. • Needing very little maintenance. (Why important?) • Only being considered at the time of use. (Means?) • Maintaining a close customer contact. (Why?) • Allowing projects to be broken into small increments. (How so?) • Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process. (How so?) • Making it easier to estimate development effort. (How so?) • Require close customer contact throughout the project so that the most valued parts of the software get implemented.

16. User Stories and Use Cases User Stories and Use Cases While both user stories anduse casesserve the purpose to capture specific user requirements in terms of interactions between the user and the system, there are major differences between them We will look at Use Cases in depth in the coming weeks. But for now:.

17. User Stories – Acceptance Tests • Another look at acceptance testing showing how it arises from a user story. • In a project following an Agile process, user stories are discussed in meetings with • the Product Owner (the person who represents the customer for the thing you’re • developing, and who writes the user stories) . • Product Owner: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork • Questions for the Product Owner might include: • What information needs to be collected to allow a user to register? • Where does this information need to be collected/delivered? • Can the user pay online as part of the registration process? • Does the user need to be sent an acknowledgment?

18. User Stories – Acceptance Testing • Here, as another example: The issues and ideas raised in this Q and A session are captured in the story’s acceptance criteria. • Acceptance criteria define the boundariesof a userstory, and are used to confirm when a story is completed and working as intended. • For the above example, the acceptance criteria could include: • A user cannot submit a form without completing all the mandatory fields • Information from the form is stored in the registrations database • Protection against spam is working • Payment can be made via credit card • An acknowledgment email is sent to the user after submitting the form. • As you can see, the acceptance criteria are written in simple language, • just like the user story. • When the development team has finished working on the user story they • demonstrate the functionality to the Product Owner, showing how each • criterion is satisfied.

19. User Stories – Acceptance TestingBenefits • Including acceptance criteria as part of your user stories has several benefits: • They get the team to think through how a feature or piece of functionality will work from the user’s perspective • They remove ambiguity from requirements • They form the tests that will confirm that a feature or piece of functionality is working and complete.

20. Where this all Fits!Putting this all together in Agile… Note: this is ‘agile’ in general, not Scrum, XP, or others. Hence terminology: iteration, stack, …

21. Where this all Fits!Putting this all together in Agile…

22. Agile LIFECYCLE