Software Requirements Specification SRS in XP

1. Software Requirements SpecificationSRS in XP Dr. Zahid Anwar

2. “Dilbert” on Extreme and Agile Programming CS428

3. Requirements Analysis • Understanding the customer’s requirements for a software system how to do it

4. Requirements analysis • Sometimes called requirements elicitation or requirements discovery • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints • May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders

5. Problems of requirements analysis • Stakeholders don’t know what they really want • Stakeholders express requirements in their own terms • Different stakeholders may have conflicting requirements • Organisational and political factors may influence the system requirements • The requirements change during the analysis process. New stakeholders may emerge

6. The requirements analysis process

7. Requirements • Requirements should be • specific, so you can tell whether you met them. • precise as necessary, but no more • Functional requirements • inputs, outputs, and the relations between them • in theory, can specify completely • Non-functional requirements • hard to specify, can’t specify completely • security • reliability • efficiency • usability • scalability • maintainability • portability • ... CS428

8. Functional requirements • Inputs, outputs, and the relationship between them • Use Cases • Formats, standard interfaces • Business rules and complex formula CS428

9. Functional requirements • Command language • The “get” command will transfer ... • Web pages • Input forms, dynamic pages • Connections to other systems • Files, sockets, XML, … • Reports, displays CS428

10. Functional requirements • Requirement: a desired relationship among phenomena of the environment of a system, to be brought about by the hardware/software machine that will be constructed and installed in the environment. • A specification describes machine behavior sufficient to achieve the requirement. • A specification is a restricted kind of requirement Lathe Required Behavior of lathe Machine Operator Specification Requirements

11. Functional requirements • Requirements define necessary objectives e.g. • software must handle error states reasonably and effectively, and provide explicit feedback to the users. • Specifications Define How to Meet The Objectives • list out all possible error states for a certain form, along with all of the error messages that should be displayed to the user.

12. Non-functional requirements • Performance • Must answer a query in 3 seconds • Usability • New user must be able to finish buying a book in 15 minutes • 90% of users must say they like interface • Maintainability • New programmers should be able to fix first bug in two weeks on the job CS428

13. Nonfunctional requirements • Technology • Must use Java • Business • Must get it finished in 1 year spending less than $1,000,000. CS428

14. XP Requirements: Release Planning • Release Planning • Happens in the beginning of every project • Made up of 2 phases: Exploration + Planning Game • Each project divided up into 1+ releases • Each release must • Be small • Must deliver enough features to be of business value • Consist of a collection of user stories to provide features

15. User Stories User story is a short description of what the business or customer wants the software to do, written by the customer in the customer terminology without techno-syntax.

16. User Stories Index Cards • Usually written on index cards because easy to • understand • Pass around • Tear up • Prioritize • One and only one business feature • Written by & focus on customer • Avoid details of specific technology, data base layout, and algorithms

17. Poor User Stories • Too vague and hard to • Estimate • Test Defines implementation details Customer doesn’t care about Tomcat or Dreamweaver

18. Splitting of Stories Split • More than one business feature • Search and • Selection functionality

19. Planning Game Example (From Textbook) • Northwind Inc Business Problem • Large reseller of food & beverage products. • Product sales over direct-mail catalogs. • Processing of orders done over the phone • from initial input of the order to • shipment and delivery of the order Create a Web presence that allows customers to self-order Northwind products and track the status of their orders all the way through to shipment

20. User Stories for Northwind

21. Quick High-Level Design Flow

22. User Story Estimating &Planning Game • Estimating • Estimates are in Story Points • 1 story point = 1 ideal day • Planning Game • Prioritization of User Stories • Priority is from 1 to n, not high, medium, low. • Velocity Determination • (No. of Devs/Load ✕ Iteration Length in Business Days • E.g. for • 8 developers • 2-week iteration • load factor=4 (time devs spend not coding (meetings, email, pair programming) • Iteration team velocity (#story pts team can complete)= (8/4 X 10) = 20 • User Story Selection according to priority (may not exceed velocity)

23. Planning Game • Planning happens once at the start of each iteration • Plan for just one iteration at a time • Planning game is the main interface between customer and development team • How it works • Customer provides all the story cards that have been written • Developers write on each card an estimate of how long it will take to implement • Developers provide an estimate of available developers X time (= “velocity”) • Customer chooses stories by priority to fill the available time

24. Velocity • Velocity = (iteration length x No of Developers) / Load Factor • Load factor is the multiplier that connects how long you think things will take to how long they actually take • e.g. you think 2 days, it takes 6, so load factor is 3 (which is fairly typical!)

25. Story Selection Two week Iteration Velocity of a single iteration (4/3 ✕ 10) = 13

26. User Stories Review

27. Planning Game Class Exercise • Groups of 5 with Subgroups • One Manager: Responsibilities include • passing information from the customers to the programmers/designers. • ensuring that project runs according to the strict time schedule • keeps both groups on task during each phase. • Presents the Stories and Design • Two Programmers: Facilitate the goals of the customer. • Velocity calculation • Story Points Estimation • Two Customers: responsible for • fine-tuning of the general specifications supplied by the instructor • Writing user story cards, prioritization and selection • Deliverables • 5-10 user stories with prioritization, velocity & high-level design

28. Toaster Toaster Mode The User inserts a loaf of bread and specifies the desired temperature and the heating time The bread is heated until the time has elapsed and the toaster is turned off automatically Toaster Mode Forced Stop The User can stop the toaster at any time before the time has elapsed by pressing a push button Toaster Mode Stop Notification When the timer expires and the heating stops and the toaster informs the user by making a beep sound. Oven Mode The User doesn’t specify a time by turning off the time Knob therefore the toaster heats to the desired temperature until the user turns it off.