Chapter 6: Requirements Engineering

1. Chapter 6:Requirements Engineering

2. Performing Requirements Determination

3. Which are the Goals of the Analysis Phase? The main goals of the analysis phase are: • To become knowledgeable in how the business operates • Understandthe user needs • Document the needs in the form of requirements • To ensure that the system meets the needs of the business • To discover how to add value to the organization through the employment of information technology The question that we are trying to answer is: “What do we need the system to do to satisfy all needs?”

4. Today’s Agenda • Introduction • Module I: Requirement Fundamentals • Module II: Techniques for Information Gathering • Review and Closedown

5. Requirements Engineering Introduction

6. 4 Concepts that Shape Business Analysis • Computers should manage our work (tell us what to do) • Use Information Technology (IT) for competitive advantage (even in government) • Reengineer to move forward • Change management is necessary

7. Computers Should Manage our Work • We no longer tell the computer to perform a task for us. In today’s organization, the computer tells us what to do. • The days of using the computer to automate single tasks are gone. Welcome to the age where computers manage our lives.

8. Use Information Technology (IT) for Competitive Advantage • Information systems (IS) are vital to the success of modern business organizations. • The analyst’s work, is oriented towards finding technology solutions to attain the competitive edge.

9. Reengineer to Move Forward • Examine your organizations and identify opportunities for reengineering. This effort would involve the radical redesign of business processes, organizational structures, information systems and values of the organization to achieve a breakthrough in business results. • Of course, you should always seek for ways to improve your business processes to add value to products and services, in an effort calledcontinuous improvement.

10. Change Management is Necessary • Please remember that organizational change deals with how organizations plan for, implement and handle change. • Overcoming resistance to change can be the hardest part of bringing information systems into a business. • Too many computer systems and new technologies have failed because managers and employees were not prepared for change.

11. Requirements Engineering Part I: Requirement Fundamentals

12. Learning Objectives • Understand the activities in the Analysis phase • Which are the Requirements Engineering Standards? • What is Business Analysis • Distinguish between business, stakeholder, solution, and transition requirements • Identify functional and non-functional requirements • Identify the source of the requirements • How to Write Requirement Statements • Document requirements

13. Which are the Activities in the Analysis Phase? Analysis activities involve defining in great detail what the information system needs to accomplish to provide the organization with the desired benefits. Four core activities that must be completed, often times in parallel: • Manage Requirements (gather information, elicit requirements, document requirements, prioritize requirements, review requirements) • Develop a logical models (i.e., Use Case diagrams, Class diagrams) • Generate and evaluate alternatives • Review recommendations with management

14. Which are the Requirements Engineering Standards? Two major organizations provide the specifications for Requirements Engineering: • International Institute for Business Analysis (IIBA): The Business Analysis Body of Knowledge (BABOK v3) describes the business analysis areas of knowledge, activities, task, and skills necessary to be effective analyst. • IEEE Computer Society, Software Engineering Body of Knowledge (SWEBOK): “The Software Requirements Knowledge Area is concerned with the elicitation, analysis, specification, and validation of software requirements.”

15. What is Business Analysis? • The Business Analysis Core Concept Model™ (BACCM™) is a conceptualframework that encompasses what business analysis is.

16. BABOK Knowledge Areas - Diagram Source://BABOK Guide V3

17. BABOK Knowledge Areas • Business Analysis Planning and Monitoring: Tasks to organize and coordinate the efforts of business analysts and stakeholders. • Elicitation and Collaboration: Tasks to prepare for and conduct elicitation activities and confirm the results obtained. • Requirements Life Cycle Management: Tasks to manage and maintain requirements and design information from inception to retirement. • Strategy Analysis: Tasks to collaborate with stakeholders in order to identify a need of strategic or tactical importance (the business need), enable the enterprise to address that need, and align the resulting strategy for the change with higher- and lower-level strategies. • Requirements Analysis and Design Definition: Tasks to structure and organize requirements discovered, specify and model requirements and designs, validate and verify information, identify solution options that meet business needs, and estimate the potential value that could be realized for each solution option. • Solution Evaluation: Tasks to assess the performance of and value delivered by a solution in use by the enterprise, and to recommend removal of barriers or constraints that prevent the full realization of the value.

18. SWEBOK Software Requirements(System Requirements) Source: http://www.computer.org/portal/web/swebok/html/ch2

19. What is Requirement? • “A requirement is a usable representation of a need.” BABOK Guide V3 • A requirement is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user (related to quality). • It is the job of a business analyst or requirements engineer to elicit, document, organize, and structure the requirements of the project.

20. Hypothetical Requirements Elicitation Scenario Stakeholder: "I want the system to be fast."Analyst: "Sure."Stakeholder: "And user friendly."Analyst: "Understandable."Stakeholder: "All documents should be then located in a single server."Analyst: "Agreed."Stakeholder: "We require a role-based security for each employee. Also must comply with the International Financial Reporting Standards (IFRS)."Analyst: "OK" (taking notes) • In the brief scenario above, how do you know which requirements are related to business needs, and which are more related to software functionality? • The question is important, because separating requirements from one another results in detailed individual requirement statements, critical for scheduling, assessing risks, and estimating costs.

21. Requirements Classification There are many, however we can classify them into four categories: • Business Requirements • Stakeholder Requirements • Solution/Software Requirements • Transition Requirements Source://BABOK Guide V3

22. Requirement Type 1: Business Requirements Business requirements are statements about higher-level statements of the goals, objectives, or needs of an organization. For example: • BR1: The bank will be able to detect fraudulent transactions. • BR 2: The claims department will be able to review the credit history of an account. • BR 3: Our hospital will record and access a medical patient’s history.

23. Requirement Type 2: Stakeholder Requirements • Stakeholder Requirement are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution (defined through requirements analysis). • StR1: The claims clerk shall be able to review the account history • StR2: The claims manager shall be able to adjust the account balance

24. Requirement Type 3: Solution Requirements • Solution Requirements describe the characteristics of a solution that meet business requirements and stakeholder requirements (defined through requirements analysis). They include: • Functional Requirements. Describe the behavior/capabilities and information that the solution will manage. • Non-functional Requirements. Capture conditions/characteristics that do not directly relate to the functionality of the solution but rather the qualities that the system must have. • One of the activities during the planning phase was to identify the system scope and identify a set of system capabilities. During the analysis phase, we define those capabilities in greater detail by describing them as system/software requirements. For example: • SRS1: The system shall withdraw a given amount of money from the checking account (but only to a maximum of $1,000 a day).

25. Requirement Type 4: Transition Requirements • Transition Requirements describe capabilities that the solution must have in order to facilitate transition from the current state to the desired state but will not be needed once the transition is complete (temporary).

26. Functional Requirements • Functional requirements are the activities that the system must perform. Functional requirements are derived directly from the capabilities identified in the planning phase. For example, if we are developing a payroll system, the required business uses might include the following functions: • GFR1: Print paychecks • GFR2: Calculate commission amounts • GFR3: Calculate payroll taxes • GFR4: Maintain employee dependent information • GFR5: Report year-end tax deductions to the IRS.

27. Nonfunctional Requirements • Nonfunctional requirements are all the operational objectives related to the environment, hardware, and software of the organization (everything else except functional requirements). Examples include: • NFR1: Solution must run in a client/server environment with Windows Advanced Server (technical requirement) • NFR2: Solution must have a one-half second response time on all screens (performance requirement) • NFR3: Solution must have context sensitive help (usability requirement)

28. Common Types of Nonfunctional Requirements • Technicalrequirementsdescribe operational characteristics related to the environment, hardware, and software of the organization. • Performancerequirementsdescribe operational characteristics related to measures of workload, such as throughput and response time. • Usabilityrequirementsdescribe operational characteristics related to users, such as the user interface, related work procedures, online help, and documentation. • Reliabilityrequirementsdescribe the dependability of a system—how often a system exhibits behaviors such as service outages and incorrect processing. • Securityrequirementsdescribe which users can perform what system functions under what conditions.

29. Requirement and Design Source://BABOK Guide V3

30. Business Rules • Business rules are requirements that depict and enforce the policy of an organization. • They are usually flexible and subject to frequent change • Some business rules are also needed to support legal and regulatory requirements, such as the ones from FCC, FDA, FAA, and so on. • Here is an example of requirements: • The system shall withdraw a given amount of money from the account, but only to a maximum of $1,000 a day. • The system shall withdraw a given amount of money from the account, limited to a maximum of three withdrawals a day. • Here is how the requirement above are stated as business rules: • SRS2: The system shall withdraw a given amount from the account. • BRULE1: Limit is $1,000 a day (24-hour window). • BRULE2: No more than three withdrawals a day (24-hour window).

31. Constraints • When NFR statements contain the word "must," that usually indicates one or more constraints that apply to the entire system; for example, complying with guidelines, laws, or industry-wide standards. • Constraints should be treated as separate from other requirement types in the same way as any other form of non-functional requirement. • Constraint example: • C1: The system must abide by Section 508 of the Rehabilitation Act of 1973. See www.section508.gov

32. How to Write Requirement Statements • ISO/IEC/IEEE 29148. Systems and Software Engineering – Life cycle processes – Requirements engineering. International Standard, 2011.

33. How do we Document Requirements? Good Solution/Software Requirements Specification (SRS) should include: • a) Functionality. What is the software supposed to do? • b) External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software? • c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.? • d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations? • e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.? Source: IEEE std 830 – Recommended Practice for Software Requirements Specification Additional Information: IEEE std 1233

34. Fi$cal– System Requirements

35. Fi$cal– AR System Requirements

36. Which is the Source of the Requirements? • Your primary source of information for functional requirements is from the various stakeholders of the new system. By stakeholders, we mean all people who have an interest in the successful implementation of the system. (BABOK Guide V2)

37. Development of Requirements – Things to Remember • Requirements developers should be careful not to go beyond the bounds of that role. That means that you should: • Correctly define all the software requirements • Not describe any design or implementation details • Not impose additional constrains • Good SRS should be (Source: IEEE std 830): • Correct • Unambiguous • Complete • Consistent • Ranked for importance • Verifiable • Modifiable • Traceable • In other words, the individual requirement shall be clear, concise, measurable, and testable.

38. State Templates for Requirements • SIMM 19 - Project Approval Lifecycle Requirement Templates (19B.3 and 19C.5) • Link: http://www.cio.ca.gov/Government/IT_Policy/SIMM_19/SIMM19.html • Other (screen below). • Link: http://www.cio.ca.gov/cpd/plansandtools.asp)

39. Requirements Engineering Part II: Techniques for Information Gathering

40. Core Techniques for Requirements Elicitation – My View • Review existing reports, forms, and procedure descriptions • Interview and discuss processes with users • Observe and document business processes • Research vendor solutions • Distribute and collect questionnaires • Build prototypes • Conduct joint application design (JAD) sessions Note that BABOK Guide V3 describes 50 techniques

41. Analysis Activities and Model Building

42. Characteristics for Successful Requirements Determination • Question everything • Be impartial • Assume anything is possible • Pay attention to details • Reframe (see the situation in another frame/belief) If we perceive something as a liability, that's the message we deliver to our brain. Then the brain produces states that make it a reality. If we change our frame of reference by looking at the same situation from a different point of view, we can change the way we respond in life. We can change our representation or perception about anything and in a moment change our states and behaviors. This is what reframing is all about. (source: Anthony Robbins, Unlimited Power (New York: Ballantine, 1987) 291)

43. Sampling Sampling is the process of systematically selecting representative elements of a population. We use sampling to make assumptions of the population as a whole. We sample to: • Contain costs • Speed up data gathering • Improve effectiveness • Reduce bias

44. Sampling Design To design a good sample, analysts need to: • Determine the data to be collected • Determine the population to be sampled • Choose the type of sample • Decide on the sample size

45. Technique #1: Review Existing Reports, Forms, and Procedure Descriptions • External Sources: External industry-wide professional organizations and trade publications • Internal Sources: Existing business documents and procedure descriptions within organization • Identify business rules, discrepancies, and redundancies • Be cautious of outdated material • Obtain preliminary understanding of processes • Use as guidelines/visual cues to guide interviews

46. Technique #2: Conduct Interviews and Discussions with Users • Effective way to understand business functions and rules • Time consuming and resource expensive • May require multiple sessions to • Meet all users • Understand all processing requirements • Can meet with individuals or groups of users • List of detailed questions prepared

47. Interviewing Checklist • Before/planning • Establish the objectives for the interview • Decide which stakeholders to interview • Decide which project team member (s) will conduct the interview • Review related documents and material • Write questions • Set time, location, and notify all participants • During/conducting • Dress appropriately • Arrive early • Ask questions including probes • Take good notes • After/reviewing • Review notes • Write interview synopsis • Identify areas which require further clarification • Send a thank you note

48. Question Types – Open-Ended Questions

49. Question Types – Closed-Ended Questions

50. Question Types – Probes • Follow-up question • Used to get more meaning out of an answer • Can be either open or closed-ended questions • Indicate that you are listening