Slide 1

RequirementsRajiv RamnathDirectorCERCS for Enterprise Transformation and Innovation (CETI)CSE 757 Software EngineeringNarrated by:

0Learning Outcomes10/18/2011Requirements1

To begin with, here are the learning outcomes from this lecture. We want you to be:Be familiar with the concept of requirementsBe familiar with techniques for requirements identification.Be familiar with requirements work-products and their use in capturing requirements.1Definition of RequirementsThe needs or conditionsthat a new or altered software systemmust meet, taking into accountthe possibly conflicting perspectivesof the various stakeholders.10/18/2011Requirements2

The needs or conditions that a new or altered software system must meet, taking into account the possibly conflicting perspectives of the various stakeholders.

Note that requirements come from a variety of stakeholders end users, business sponsors, technical groups, regulatory bodies etc. Requirements from a stakeholder might be in conflict. For example, the business sponsor may require low cost while the end user may require high performance. Thus, trade-offs have to be made, based on how important a stakeholder and his requirements are.

2How do you find and capture requirements?Domain and Problem AnalysisAnalyze a piece of the businessExamine value chain activitiesDevelop Balanced ScorecardsExamine existing business processes and transactionsUser and domain expert interviewsEthnographic studies:Field observations, studies and interviews (Intuit: follow-me-homes: http://blog.intuit.com/trends/what-is-a-follow-me-home/)Could be longitudinalRequirements are then captured - in work-products, or as tacit knowledge10/18/2011Requirements3

Domain and Problem AnalysisAnalyze a piece of the businessExamine value chain activitiesDevelop Balanced ScorecardsExamine business processes and transactionsNote: You did some of this before earlier probably without knowing that what you were doing is analysis.User interviewsEthnographic studies:Observations (Intuit: follow-me-homes) http://blog.intuit.com/trends/what-is-a-follow-me-home/Embedded field studiesLongitudinal research studies that look at progression over time.In-depth interviewsRequirements are then captured - in work-products, or as tacit knowledge

3Requirements Work Products10/18/2011Requirements4

Let us now look at requirements work-products.

4Requirements Work Products Problem StatementContent:Business domain, goals, objectives, stakeholdersWhat are we trying to accomplish, for whom, and whyNot focused on solutionHow:Written with customer, before the project begins Shared, incomplete, consensus achievedFormat:Free format text with sections such as: Objectives, Success Criteria, Itemized requirements, Stakeholders etc.10/18/2011Requirements5

The first requirements work product we will look at is the Problem Statement. The focus is on the problem, or need, not the solution. A text description of business goals, objectives, problem to be solved. Capture what RESULTS the solution is supposed to deliver as opposed to the solution itself.

Most of the time a problem statement is captured in free-form text with perhaps a few sections.

5Problem Statement ExcerptTheFirm is a firm consisting of 3 business - a law firm, a title company and a processing company, doing high-volume legal work, charging fixed fees and with a larger ratio to staff vs. attorneys. A high-volume foreclosure law firm is different from a regular law firm; it cannot rely upon the attorney to get the work done. The high-volume law firm is dependent on its case management system to keep track of the cases and to identify what must be done in those cases and when. We are a high-volume law firm. As a result, we need an automated workflow system, one that tells the user what needs to be done and when. We need a system that allows us to handle the volume of cases with consistency, high quality and efficiency, and integrated with the systems and processes of our customers.10/18/2011Requirements6

Part of a problem statement from a project done with a law firm. Non-traditional law firm. Did not do litigations in court or prepare legal briefs. It was a high-volume law firm. Few lawyers, most work done not even by paralegals but by employees trained in the administrative tasks needed to process foreclosures.

Organization measured based on throughput and efficiency. Hence a good candidate for a software system that could guide employees without legal training in properly following the process, creating the necessary documents and so on.

6Requirements Work Products Business CaseJustification of expense - effort or monetaryViewpoint from multiple stakeholdersItemized cost estimates, including opportunity costFree formatCould include soft benefits: social, environmental, ethical and politicalStructure as: COST vs. BENEFIT

10/18/2011Requirements7

The business case is a justification of the expense and effort of doing the project. It should be structured in two parts cost vs. benefit (value). Unlikely at start of project of the cost or benefit. So this should be refined as the project proceeds. Cost might be in $$ or hours of work, benefit might be intangible. Make the extra effort of converting benefits to $$ if possible.

7Example Business CaseEstimated cost:$1M, based on staffing size and estimated duration of 1 yearEstimated Benefit (over 1 year):Reduction in training costs: 1 person month per employee * turnover rate = $100,000Reduction in penalties due to errors: $250,000Increased revenue due to increased capacity from 200 cases to 250 casesCompetitive advantage due to a demonstrable assetEtc.10/18/2011Requirements8

Example business case from the law firm example.

A. Estimated cost as $1M. Well look at better ways to estimate the cost in a more refined in a later module.

Here we estimated the cost based on the resources applied software developers, architects, DBA, users, equipment costs. Rough, but gave the owner an idea that this is likely to be an expensive project, and should expect at least a $1M worth of return.

B. Estimated Benefit:

Reduce training costs because training doesnt have to be one-on-one in person. Dont have to train on process, only on system. Saved 1 month per year, multiplied

Delays in process caused penalties. System could save these costs. About $250K per year.

Made each person more productive because he didnt have to do manual things, about 25%. So more cases 50 more per year.

Total of $750K per year in cost savings.

But also, gave the law firm a tangible asset that gave it demonstrable competitive advantage with respect to winning new business.

8Requirements Work Products StoryboardNarrativeOf how the organization would work using the system, OROf how the organization currently works

10/18/2011Requirements9

A storyboard is a very useful work product to collect requirements. Speaker comes and tells a story that illustrates how an organization typically works, how users may interact with the system (the system vision). Natural work product to capture requirements. This is an informal narrative, from which the other structured or more systematic work products can be derived.

9Requirements Work Products Use Case ModelCaptures functional requirementsConsists of:Actors (humans, external systems) hierarchyUse CasesExtends vs. Uses (SEE NOTES PAGE)Use Case Diagram context modelUML NotationDrives all activity - starting with analysisDrives acceptance tests

10/18/2011Requirements10

Very popular work products is a Use Case Model, and consists of 3 components: (a) the actors that use the system human as well as system actors (b) Use Cases visible interactions of the system with the actors captured and packaged in an intelligent manner (c) Use Case Diagram shows the context of the system that is, its place in its environment.

Use Cases typically drive the rest of the process. That is, other work products are often derived from Use Cases, such as the Acceptance Plan which we will see later that closes the loop with respect to requirements.

10Example: Actors HierarchyActor:TheFirm EmployeeTheFirm UserIntake ProcessorTitle AdminTitle ProcessorAttorneyConsultantTitle Examiner

10/18/2011Requirements11

Example of the actor inheritance hierarchy from the law firm example.TheFirm EmployeeTheFirm User not all employees use the system. Now different rolesIntake ProcessorTitle AdminTitle ProcessorAttorneyConsultant users outside the firmTitle Examiner

Defines the prototypical users of the system. Structured in a hierarchy, and could be internal as well as external to the organization.

11Example Use CasesDepartment: IntakeActors: Intake ProcessorNormal Use CasesIntake Processor Claims Case from Client SystemIntake Processor Assigns AttorneyIntake Processor Assigns Title ExaminerExceptional Use CasesChange or Correct Attorney AssignmentChange or Correct Examiner AssignmentAttorney leaves TheFirmExaminer leaves TheFirm

10/18/2011Requirements12

Example use cases from the system we developed. Actor is Intake Processor, assigned to a department called Intake. Three use cases capture how the actor normally interacted with the system (hence we have termed these Normal use cases.

There were also 4 exceptional use cases that capture how the actor interacted with the system in rare situations.

Useful to create two categories of use cases to help in prioritization.

Also, while a use case may be rarely used, it may be an important use case say one against which the design of the system must be validated.

12Use Case DiagramShows context of systemSystem boundaryActorsUse case namesRelationships

10/18/2011Requirements13

A Use Case Diagram shows the boundary of the system to be designed, the use cases of the system, and which actors interact with which use cases.

What is inside the system boundary is what is to be implemented.

13Example Use Case Diagram10/18/2011Requirements14

Intake ProcessorClient System

On this example use case diagram you can see two actors a human actor and a system actor (the system from which foreclosure cases are to be pulled).

The use case diagram shows the context of the system. You see which use cases interact with which actor. It also shows a larger use case being refined to smaller use cases.

14Requirements Work Products - ScenariosAlso known as FlowsUsed to refine a Use CaseOne path through a Use CaseHappy PathUnhappy pathsAssumptionsOutcomes10/18/2011Requirements15

From the Storyboard, you could derive Use Cases. But Use Cases are still high level. Have to breakdown use cases further. For example, User Withdraws Money From ATM can be broken down into several scenarios, namely: User Withdraws More Than Limit from ATM, User Enters Incorrect Password.

These scenarios are typically broken down into happy scenarios, such as User Withdraws Less Than Balance From ATM or unhappy scenarios, such User Enters Incorrect Password.

Note two other components of scenarios, namely, Assumptions and Outcomes. What has happened before the scenario are the assumptions. What happens once the scenario executes are the outcomes. For example, the assumption could be that the user has entered his card and typed in his password. This the scenario would start from that point onwards.

Outcomes are what has happened after the scenario has executed. Thus, in the happy path scenario, the user would have successfully withdrawn his money. In the unhappy path scenario, the outcome would be an error message saying Incorrect Password or Withdrawal Not Authorized.

15Example ScenariosUse Case: Intake Processor Claims Case from Client SystemPrimary scenario (or Happy Path)Case is successfully claimedAlternate scenarios:Client system has invalid requestDuplicate case is launchedCase is incorrectly launched

10/18/2011Requirements16

Example scenario from the Foreclosure system drawn from the Use Case Intake Processor Claims Case from Client System

Primary scenario (or Happy Path) occurs when the case is successfully claimed.

Unhappy paths (alternate scenarios) are things like the case having invalid data, being a duplicate case, or the case doesnt have sufficient data to be launched.

There could be several happy paths: E.g. take the use case User Makes A Deposit. This could have the following several happy scenarios: User Deposits Check, User Deposits Cash, and so on.

Granularity of use cases and scenarios is up to you. You could capture every scenario as a use case, but then you would lose the big picture, and make mistakes like implementing the UI of each scenario, which should be similar in terms of look and feel being from the same use case, slightly differently.

16Requirements Work Products User StoriesUsed to capture functional AND non-functional requirementsFormat: As an I want to to achieve 10/18/2011Requirements17

A User Story is a work-product equivalent to a scenario. The format of a story is: As an I want to to achieve A User Story may also be used to capture non-functional requirements, as we will see in the later slides.

17Example Story Functional RequirementAs an Intake Processor I Evaluate a Case as follows:I am notified of a new case in the client systemI look through the case to see if it is a valid and new foreclosure caseIf it is a new foreclosure case, I can accept the case, thus preventing another company or another intake processor from claiming itIf not, I release it.so that I may Accept it for Processing or Reject it10/18/2011Requirements18

As an Intake Processor I Evaluate a Case as follows:I am notified of a new case in the client systemI look through the case to see if it is a valid and new foreclosure caseIf it is a new foreclosure case, I can accept the case, thus preventing another company or another intake processor from claiming itIf not, I release it.so that I may Accept it for Processing or Reject it

Hope you see how a user story may be written.

Later you will see a slide where a story captures a NON-functional requirement.

18Requirements Work Products Non-Functional RequirementsAlso known as architectural, assurance, or design requirementsVERY important - can break a projectBut cannot make it Example categories: Performance, Availability, Compatibility, Usability, Security, CostDrives DESIGN not analysisWho does this:Customer, project manager, team leaderProcess:Make it real for the system under considerationVerify coverage against use casesMust be testable10/18/2011Requirements19

Just as the use case model captures the functional requirements of the system which is what the system is supposed to do, the WHAT of the system non-functional requirements capture the HOW of the system.

Once again, take the situation of an ATM machine; the use case is user withdraws cash from the ATM. The non-functional requirement is a typical user is able to withdraw cash from an ATM within 15 seconds of inserting a card. This is not a functionality requirement, because the functionality requirement is simply a user withdraw cash, it is what is known as a non-functional, or design, requirement which puts a specification on how the functionality must be implemented. That is, it must be implemented in a way such that a user can withdraw with 15 seconds.

Both functional and non-functional requirements translate into behavior of the system, because if the FR is user withdraws cash, then there has to be behavior in the system that allows the user to withdraw the cash, and a NFR that says a user must be able to withdraw cash within 15 seconds, it makes the system work fast enough so that it can deliver the cash within 15 seconds. So keep in mind that both kinds of requirements ultimately result in behavior of the system.

The distinction is that NFRs drive the design of the system, not the analysis of the system. So when you are thinking about what the system is supposed to do, you can do that by looking only at the FR; its when you try to design the system so that you can build it that you start to look at the NFRs.

The reason to separate the two is to allow the software engineering team to separate analysis and design so they dont too quickly paint themselves into a corner with a particular solution, when there are better ones around. Now, NFRs can be categorized in various ways, typically speed, performance, scalability, modifiability, usability, etc.19Example Non-Functional RequirementsPerformance:Based on studies of user attention span synchronous tasks must respond within 5s in system steady stateUsability:Prototypical LawFirm users must be able to learn to use the system within 10 daysScalability:User growth rate: +20 users per year3000 new cases per year2 new company acquisitions per year10/18/2011Requirements20

On this slide are some example NFRs in three categories: performance, usability, and scalability. Keep in mind that an attempt has been made to quantify these requirements in the context of the system being built. That is, we are not saying things like the system must be high performing, usable, and scalable, we are quantifying exactly what performance, usability, and scalability mean.

This is very important. Its very important that the quantification of these NFRs be in the context of the system, in other words, its the quantification thats different from system to system. For example, lets take usability. We say that user must be able to use the system within 10 days. Why have we said within ten days? Remember the original rationale for building the system: we would be able to save about a month in training time for each user. Ten days has been decided as the appropriate time to train each user. If it took more than ten days, then maybe we wouldnt save as much money as we anticipated. Thats where the requirement came from: a business requirement!

Secondly, you can see its probably feasible to train a user on this system, even without seeing or designing it, you can see that it is a reasonable requirement that people learn how to use it within 10 days. On the other hand, imagine a system that performs robotic surgery. It certainly wouldnt be a reasonable requirement that a surgeon learn to operate the machine within ten days because there is a sense that robotic surgery is dangerous, so the surgeon would require weeks of training. Just keep this in mind: NFRs have to be quantified. The quantification has to be done within the context of the system.

There are not many standard quantifications. By the way, here is an example of a standard quantification: the first one, that says the system must respond within five seconds. That one came from a study that says users lose interest in ANY system that doesnt respond within five seconds. So that requirement did not come from this particular system, but the others did. Both came from the business case of what the system was supposed to address.20Example Non-Functional Requirements Captured as StoriesAs a TheFirm User, I want to be able to run your product on all versions of Windows from Windows 95 on.As the TheFirm Systems Administrator, I want the system to use our existing orders database rather than create a new one sot that we dont have one more database to maintain.As a TheFirm User, I want the program to be available from 8 am to 6 pm Mondays through Fridays.As TheFirm Partner, we might want to sell this product internationally.10/18/2011Requirements21Reference: User Stories Applied: For Agile Software Development, Mike Cohn, Safari http://is.gd/eyzsl5

Here are examples of non-functional requirements captured as stories.

The first one is a portability requirement.

The second is a compatibility or integratability requirement.

The third is an availability requirement.

And the fourth is a business requirement, all captured as stories.21Requirements Work Products Prioritized RequirementsPrioritized requirementsHow to prioritize:Customer valueRiskPriority is a combination of:Importance or Business ValueVital, important, would be niceand UrgencyOther functions depend on it etcCould be coarse granularity, partitioned by use-case, or fine granularity, partitioned by scenarioDrives prioritization of Acceptance Plan and Project Management work-products10/18/2011Requirements22

The next work product is a work product known as prioritized requirements. You might think that this belongs as a project management work product and you might be right. The basic idea here is to take all the requirements, both functional and non-functional, and prioritize them.

The prioritization is generally done on two axes: business value and urgency. Business value, or importance, speaks to how much revenue you could generate from this product. Urgency comes from whether other pieces of functionality depend on it. For example, a login use case has no business value because it generates no revenue, but it has high urgency because other functions depend on it.

Now when you prioritize requirements, you can prioritize them at a coarse granularity by use case or non-functional requirement or you can prioritize it at a fine granularity, such as by scenario within a use case. Even the non-functional requirements can be prioritized in a granular manner, for example, you can have NFRs attached that serve as use cases that have to be implement first, and so on.

So once again, the whole reason for prioritizing the requirements is to give an order to the development process and this in turn will drive two things: an acceptance plan, which we will talk about next, and the project management work products because the prioritization will determine the order of which things need done.22Requirements Work Products Acceptance PlanAcceptance planCommits customer to a deterministic way of determining acceptanceParticipants: decision makers, stakeholdersShould include time to fix clausesLess important for internal projects10/18/2011Requirements23

Now we come to the last work product in this list of work products. This work product is known as the acceptance plan and it essentially closes the loop with respect to requirements. Just as the storyboards, use cases, and storyboards capture what the system is supposed to do, the acceptance plan outlines the process for validating that the system performs as it was required to do. So if everything else was a requirement, this one is a verification and validation step as to whether the requirements were implemented correctly and were the right things to implement.

An acceptance plan is also a contract closure document because it commits the customer to a deterministic way of figuring out acceptance. In other words, the idea is not to give the customer too much wiggle room with respect to requirements. It makes the customer agree to saying that, when the system is finished, I will validate that the requirements are met in this manner. With respect to the acceptance plan, it is made jointly with the customer, because when customers are asked how they will test the system, they will be more precise in giving the requirements in the first place and this is meant to be a collective effort, not an adversarial effort. Typically in these acceptance plans, there is a time-to-fix clause, so there is some wiggle room in the sense that the customer might say you think you passed this test and I agree that from your perspective, you did, but I really meant this slightly differently and it doesnt seem much different from what you thought it was, so could you fix it? Or it could be a test that you genuinely missed because you missed some situation where your software would fail. So typically an acceptance plan will include a time-to-fix clause, for example, we will fix any bugs that are reported within thirty days.

An acceptance plan is less important for an internal project because, after all, its within the same company, so you might know someone who can fix it.

One quick thing, I dont know how many of you have ever bought a house or built a new house especially, there is usually a walkthrough at the end, just before you close, where you walk around with a checklist. The idea is that if you find anything wrong, the builder will fix it for you. Thats essentially what an acceptance plan is.23Example Acceptance PlanAll functional requirements in the released system must pass acceptance testingPerformance:Based on studies of user attention span synchronous tasks must respond within 5s in system steady stateTest with:5 concurrent users10000 cases in databaseUsability:Prototypical LawFirm users must be able to learn to use the system within 10 daysTest with Joe, Sarah, Barack and JohnScalability:User growth rate: +20 users per year3000 new cases per year2 new company acquisitions per yearQuestion: How will we test these elements? Are these requirements under-specified?10/18/2011Requirements24

Heres an example acceptance plan. I hope that, when reading through this, that you notice one key thing. All the items here are connected to your non-functional requirements. Typically, there is less discussion about whether a functional requirement has been met. So if you have a functional requirement that says a user withdraws money from an ATM, you test the system, you put your PIN in and the system gives you money, and it means the functional requirement requirements pass.

So in a typical acceptance plan, the acceptance criteria are typically not spelled out in detail, theres typically just a line that says all functional requirements must pass acceptance testing, or something like that. Of course, if there is a very critical functional requirement, you might spell that out in detail, but typically all that is said in an acceptance plan is all that was said that it was supposed to do, it does.

But when it comes to the non-functional requirements, things arent so simple. For example, lets say there was a performance requirement that says the system must respond in 5 seconds. The customer is supposed to test it; does that mean he tests it with nobody else on the system? Does that mean he tests it with 1000 concurrent users on the system? With no cases in the database? With a million?

This quantification that I talked about that needs to take place on the non-functional requirements, a further quantification has to take place for the acceptance plan because a deterministic test must result from this process that a customer can explicitly do. The passing or the failing of that test should be clear, which constitutes a failure of the acceptance test.

You will see that in each of these cases, performance, usability, and scalability, we have taken the NFR and further refined it to make it deterministic and make sure that it is clear how to perform the test. So take a look at this. With respect to performance, we say five concurrent users and ten thousand cases in the database. With usability, we say to test with these four people. Now my question for you is to think about how, for scalability, you could take the NFR and create deterministic tests tests that you can actually do to pass or fail the acceptance test.24Agile Processes and RequirementsLive users (serve as tacit holders of requirements)User storiesSystem testsAny work-product from a structured process, but developed in an agile wayE.g. Whiteboard sketches10/18/2011Requirements25Reference: Beck, K. Extreme Programming eXplained: Embrace Change. Safari.

When it comes to agile requirements capture, here are the work products. The first work product is the customer himself. The customers in agile requirements gathering is a first-class work product because the thinking is that the customers are the true repositories of the requirements. However, there are some documents that are created to capture requirements work products. The first such work product is a user story. Youll see examples of user stories in the subsequent slide. The user story is used to capture both functional and non-functional requirements. I hope you still remember what non-functional requirements are! The accepted format for capturing a user story is show here: As I want so that . Youll see an example of that in the next slide.

The third work product with respect to requirements capture in agile processes is the system test itself. This is a very novel and unique concept in agile processes. That is, the system test is both a validation of the system but its also a specification for the system. The thinking is that, if you can write a test for a piece of functionality correctly, then you probably have a very good understanding of what the functionality is supposed to be. Therefore, the test can serve as a requirement.

Finally, agile processes are very welcoming, in terms of accepting work products, so if you feel that there is a work product that you feel does make sense in an agile process, the agile advocates say go ahead and use it. So pretty much any work product from a structured process can be an agile work product, but the intent is to develop it in an agile way, so you dont spend time documenting and using a tool and printing pretty documents, you might just draw it on the whiteboard and photograph it.

When it comes to capturing requirements using agile processes, the tradeoff is between less documentation for more shared, tacit knowledge, whereas with structured processes, youre putting more into documentation and trusting less on the shared knowledge of the people on the team. So the basic principle behind agile processes is to capture just enough requirements and document them and trust in the shared knowledge of the people working on the team to know what the complete requirement is.25Partnership for PerformanceUse Case Sketch

Here is an example of a Use Case Diagram drawn informally on a whiteboard and then photographed.26What have we learned?10/18/2011Requirements27

Finally, we revisit the learning outcomes to go over how we covered them.Be familiar with the concept of requirements. We covered this by explaining what requirements are, and that requirements represent the perspectives of multiple stakeholders.Be familiar with the techniques for requirements identification and capture. For this learning outcome we briefly described several requirements identification techniques.Be familiar with requirements work-products. Finally, we described and gave examples of work-products in which to capture requirements. Here we noted that, in agile processes, certain concerns of requirements may be tacitly captured, or by using informal work-products, such as sketches.

27ReferencesDeveloping Object-Oriented Software An Experience-Based Approach (online):Chapters 9 on Requirements REQUIRED

10/18/2011Requirements28

Here are the reading assignment for this lecture:Developing Object-Oriented Software An Experience-Based Approach: Chapters 9 on Requirements. This reading is REQUIREDEthnographic study of IT use in a home. This needs to be read for the project.

28Thank you!10/18/2011Requirements29nullBlues5929.811