Effective Requirement Collection

Requirement collection and analysis is an important part of every development process. It is a leading indicator of a project's success or failure. In this presentation, I give a brief overview of the steps involved walking through an example.

Transcript

1. Effective requirement collection Dara Duman emarketdesign.com
2. Who am I? • 15 years of software development experience • Project Manager, Business Analyst, Data Architect, Developer • Worked in many enterprise projects in financial, retail, technology industries • 5 years as a founder and core developer in WP App Studio WordPress Design and Development Platform • B.S. in Mechanical Engineering (Military Academy - 1992) • Masters in Hotel, Restaurant and Institutional Management (Penn State - 1998) • Masters in Management Science and Information Technology (Penn State - 2000)
3. Why quality in requirement collection is important? 40% to 60% of all software defects found in software projects are traceable back to incorrect requirements collection
4. ..And we all pay for it • Redevelopment costs • Costs associated to delay in time-to-market • Operational costs of incorrectly built software in production • Customer and developer frustration…. and on and on..
5. What is a requirement?
6. There are two types of requirements: • Functional • Non-functional
7. Functional Requirements • Defines what software needs to do • Defines the scope of the system • Defines the system boundaries and connections to the external system(s) • Defines the business rules - the most will be of this type
8. Non-functional requirements • Defines the look and feel of the system • Includes user interface, security, performance, legal, social, maintainability, portability, hardware, and more
9. What is a good requirement? Part I • Complete - the criteria must be set to define what’s complete • Correct - accurate and represents fact or truth • Feasible - can be done without any contradiction to the other requirements • Needed - absolutely required for the system to its job • Prioritized - provides a blueprint for iteration plan
10. What is a good requirement? Part II • Clear - not prone to misinterpretations • Testable - can be verified once implemented • Unique - No dupes • Traceable - can be linked to a person or a group, use case, model, source code or other higher level requirement • Approved - someone or a group must approve
11. Who and what do we need? • Subject matter experts (SME) - people who know • User - people who will use the system. Observe what they do, like, or don’t like • Existing systems - Manual or implemented , similar or competing
12. Good one? "The customer shall enter first name, last name, email and mailing address in order to get a free gift" • Uses shall statement - expressing an order or instruction • Defines who will do it - customers • Defines data needed to perform - first name, last name, email and mailing address • Defines what needs to be done - in order to get a free gift
13. Bad one? "We may need first name to be able to send out gifts" • May - no clear instruction • Who will get the gift ? employees, customers or contractors • Whose first name is it? • Who are we? • How do we send? Don’t we need address of the recipient?
14. R we done yet? Voices from the trenches.. • Look , I gotta start coding otherwise I will not be able make my deadline • Should I ask this question to the client? She must be sick of hearing about requirements… • Let’s come out with something then we will talk about it • I hate documentation. I want a pizza party not another requirement collection session • I swear to Tom Cruise I will quit immediately if I get another invitation to the req meeting • It’s been sometime and still we do not have any code. Did I pay for this?
15. Not yet! Ladies and gentleman. The next destination: • Create Use Cases - the text document and the UML diagram
16. What is a Use Case? I googled it. • A use case is a series of related interactions between a user (or more generally, an “actor”) and a system that enables the user to achieve a goal. • A use case describes the system's behavior as it responds to a series of related requests from an actor • A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. • A use case is a list of actions or event steps, typically defining the interactions between a user role and a system, to achieve a goal. • A use case is a software and system engineering term that describes how a user uses a system to accomplish a particular goal.
17. A Use Case has: • Overview - This scenario describes a Customer getting a free gift online • Notes - All major modern browsers must be supported • Actors - The user(Customer) who wants to get a free gift • Preconditions - Customer has access to internet and navigated to our site and Free Gift form page. • Scenarios - Shows step by step interaction between an actor and the system producing a software reaction
18. A scenario example Action Reaction Customer fills out first name, last name, email, and mailing address The system verifies email and mailing addresses are correct and not already exist Gift Vendor get Customer information and sends out the gift The system send notification to Customer that her gift has been shipped
19. The diagram
20. What did we learn? • Spend sometime producing quality requirements or pay the price • Requirement collection is a process • Software development is a team sport • Think, ask questions, and document before jumping into code • Practice and read more to do better the next time • Ohh.. Use cases and all other stuff :-)