Requirements Seminar

1. Requirements Seminar

2. What is a Requirement? • Something that the product must do or a quality that the product must have • Things you should discover before starting to build your product

3. What is a Requirement? • What the Stakeholder • Needs • Wants • Asks for • Expects • Can have • A set of specific criteria that a product must meet in order to be acceptable to the stakeholders “Your customers are not buying a product. They’re buying your assurances that their expectations for that product will be met” - J Guaspari

4. What is a Stakeholder? • People who have a vested interest in the product – will somehow be affected by its use • People who have requirements for the product • Before you can identify all the requirements, you must identify all the stakeholders. • Include the list of stakeholders in your requirements specification.

5. Why do we need Requirements? • Define the product • Define product quality • Help control complex projects • Help manage Stakeholder expectations • Improve compliance with: CMM, ISO, IEEE, etc.

6. Capability Maturity Model (CMM) • Congress founded the Software Engineering Institute (SEI) at Carnegie-Mellon University in 1984 to improve the practice of software engineering. • First version of CMM published in 1989. • Mature = predictability is high, risk is low

7. CMM (continued) • Five levels of maturity • Initial (75% - 85%) • Repeatable (5% - 10%) • Defined (3% - 7%) • Managed (2% - 3%) • Optimized (> 2%) • Each level defines Key Process Areas (KPA) and key practices within each KPA.

8. CMM Level 2 • Project-focused • Formalize the planning and mgmt. of individual projects. • Six Key Process Areas (KPA) • Requirements mgmt. • Software project planning • Software project tracking • Software quality assurance • Software configuration mgmt. • Subcontractor mgmt.

9. The Spirit of CMM • Say what you do and do what you say. • For Level 2, • Repeat processes from project to project • Study the results • Improve the process if necessary • Accumulate artifacts that substantiate the top bullet point.

10. Establish a Repeatable Process • Identify stakeholders • Mine • Define • Refine • Combine (requirements specification) • Signoff • Change control, reuse library

11. Sponsor Current Users New Users Management Customers PMO Development team Legal Marketing Government Industry Public Special interest groups Existing IT systems Production support team ??? Identify Stakeholders

12. Mine for Requirements Partners Customers Business Plans Personal Goals Bug Reports Change Requests Analysts Domain Experts Industry Analysts Site Visits Competitive info Users Problem Domain

13. The Key • Listen • Re-state • Do not stop until YOU have a clear picture – YOU manage the expectations – YOU must have the vision. • Document your understanding • Get signoff on your document

14. Requirements Should Address: • Business impact • Business need • Impact on the organizational processes • Impact on the existing and planned systems • Business and technology strategies

15. Techniques for finding potential requirements • Interviewing • JAD (Joint application development) • Brainstorming • Facilitated Sessions • Prototyping • Use Cases • Usability Studies • Document Gathering • Inspection

16. More techniques for finding potential requirements • Surveys • Business procedures and standards • Data flow diagrams • Client Liaison • Data and process models • Data dictionary definitions • Existing code unit specifications • Comments in existing code • Reuse library

17. Stating Requirements Accurately • Essential Characteristics of Requirements • Complete • Unambiguous • Consistent • Verifiable • Precise • Detailed

18. Define Requirements - Requirement Attributes • Description • Rationale • Source • Source date • Unique identifier • Requirement type • Requirement sub-type • Requirement level • Priority • Test Case

19. Description Use consistent format Verb - Modifier - Direct Object – (on condition) Examples • Capture (verb) customer (object modifier) information (object). • Calculate (verb) monthly interest (object modifier) payments (object). • Issue (verb) warning (object modifier) alert (object) on error (condition). Emphasize “what” not “how”.

20. Types of Requirements • Functional requirements • What will the product do? • What, not how • Non-functional requirements • What qualities must the product have? • Constraints • What limitations exist regarding the way the product is produced?

21. Sources of Requirements • Client requirements • Technical requirements • Audit and control requirements • Corporate standards • Operational requirements • Regulatory bodies

22. Additional Sources of Requirements • Manual and administrative requirements • Scheduling and performance requirements • Database requirements • Security requirements • Audit and control requirements

23. Refine Requirements • Must pass quality check before being added to requirements specification and database. • Must verify and validate. • Decomposition

24. The Need for Quality Requirements • 60% - 66% of errors originate with requirements and analysis activities. • 45% of problems requiring maintenance are detected after completing acceptance tests. • The cost of fixing problems during final testing is 50-100% higher than during requirements specifications.

25. What Is Quality? • The level with which a product meets all its defined requirements; • Therefore, • You can’t measure quality without fully defining the requirements • Each requirement should be measurable/testable.

26. Verify and Validate • Requirements validation and verification are the joint responsibility of the test analyst and the client/end user. • Validating requirements before coding begins minimizes costly design and code modification. • Acceptance and Integration tests begin by validating that the requirements meet user’s expectations and are testable.

27. Requirement Test Case 1 2 3 4 5 6 Validate sign-on x Invalid term ident x Validate password x Password/ Signon error x Validate Main Menu x Re-enter O, X, M, R x Validate Customer # x Customer # Required x Field entry too long x Customer ___ not found x Validating requirements

28. Decomposition • Identifying requirements in a top-down fashion • Process of refining requirements • Requirements are categorized at three major levels of detail: • High • Intermediate • Detail

29. Decomposition • High Level Requirements • Broadest category of functions • Major business processes • Operations manuals, user manuals, procedures • External systems interfaces • System controls • Special requirements • Volume/Stress requirements • Backup/Recovery requirements • Performance requirements • Used to define and validate the build structure

30. Decomposition • Intermediate Level Requirements • Components of intermediate level requirements may include: • Sequences of actions to be taken • Information to be displayed or reported • Error routines and messages • Interfaces to other system modules • Transaction descriptions • Edit, update, etc. • Used to define and validate test runs

31. Decomposition • Detail Level Requirements • Specific steps in application processing, such as: • Action steps • Field definitions • Edit criteria • Calculations • Error messages • Used to develop test cases

32. Validating Detailed Requirements • Requirements Decomposition • Complete when each defined requirement can be validated by one or a small number of test cases • If you can not develop a test case for a requirement, you need to dig further • If you are having difficulty developing test cases, other design activities focusing on the specific function in question should be stopped until requirements can be clarified or augmented

33. Watch Out For Words Like: Often Always Sometimes Never Usually Fast User friendly Timely Most of the time Quickly Could Might/May Good Satisfactory “BAD” words

34. Be careful of: • Unintended implications of certainty • always, never • Passive tense phrases • the counter is set • Pronouns • for which references are not clear • Unclear comparatives • earlier easiest most valuable

35. And… • Unqualified attributes • flexible, efficient, organized • Ambiguous words • quickly, adjacent • Contractually troublesome phrases • where applicable

36. Combine and Review • Produce requirements specification • Should include • Product purpose • List of Stakeholders and their roles • Constraints • Assumptions • Functional requirements • Non-functional requirements • Consistency check, missing requirements

37. Obtain Signoff • Client understands the system • IT understands the requirements • Go directly to change control

38. Change Control • No requirements are changed, added or deleted without going through the change control process. • A change request form is filled out specifying the requested change, the source and why the request is being made. • The change is analyzed and the potential impact is added to the form. • Change control board reviews and sponsor signs off.

39. Reuse Library • Collection of artifacts • Enables repeatability • Saves time, effort, re-work • Many constraints will likely be the same • Stakeholder list will likely be similar • Use items as needed

40. Lessons Learned • What techniques were used to identify requirements? • How well did they work? • Can they be improved upon? • Document

41. Discussion Contact Info: Bill Ax – Account Executive 608-233-8201 billax@spherion.com Mike Lawler – SQM Practice Director 630-919-2912 michaellawler@spherion.com