03RequirementsSpecification

03RequirementsSpecification - Requirements specification...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Requirements specification CSE432 Object-Oriented Software Engineering Requirements analysis and system specification Why is this the first stage of most life cycles? Need to understand what customer wants first! Some call this step requirements gathering Requirements are a contract between you and the customer (OOSE theme) Some distinguish requirements gathering and system analysis steps A top-level exploration into the problem and in some sense a discovery of whether it can be done and how long it will take Though customer may not fully understand it! Requirements analysis says: "Make a list of the guidelines we will use to know when the job is done and the customer is satisfied." System specification says: "Here's a description of what the program will do (not how) to satisfy the requirements." Goal of requirements elicitation is to understand the customer's problem "Editor with undo" A very simple, initial requirements spec Why might a small and concise initial spec be a good idea? Fosters initial buy-in and agreement by everyone on the team Real-world specs are usually much longer, though What's the purpose of a purpose statement? Why is scope important? Why definitions? Other possible general requirements: Business context: organization sponsoring the development of the product User characteristics: profile of user community, expected expertise with system & domain User objectives: "wish list" from user's perspective, in line with business objectives Interface requirements: GUI, API, communication interfaces, software interfaces Functional (what behaviors it does) and non-functional (how it does them) Functional requirements describe system behaviors Priority: rank order the requirements in importance Criticality: how essential is each requirement to the overall system? Risks: when might a requirement not be satisfied? What can be done to reduce this risk? Non-functional requirements describe other desired attributes of overall system-- Product cost (how do measure cost?) Performance (efficiency, response time? startup time?) Portability (target platforms?), binary or byte-code compatibility? Availability (how much down time is acceptable?) Security (can it prevent intrusion?) Safety (can it avoid damage to people or environment?) Desiderata for a requirements specification Should say what, not how. Why? Correct: does what the client wants, according to specification. This quality is like motherhood and apple pie--How can you accomplish this? Ask the client: keep a list of questions for the client Prototyping: explore the risky aspects of the system with the client But how do verify a requirement like "user-friendly" or "it should never crash"? Verifiable: can determine whether the requirements have been met Unambiguous: every requirement has only one interpretation Consistent: no internal conflicts If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another Complete: has everything designers need to create the software Understandable: stakeholders understand it well enough to buy into it Can there be a tension between understandability and the other desiderata? Modifiable: requirements change! Changes should be noted and agreed upon, in the spec! Use cases First developed by Ivar Jacobson Now part of the UML Emphasizes user's point of view Explains everything in the user's language A "use case" is a set of cases or scenarios for using a system, tied together by a common user goal Essentially descriptive answers to questions that start with "What does the system do if ..." E.g., "What does the auto-teller do if a customer has just deposited a check within 24 hours and there's not enough in the account without the check to provide the desired withdrawal?" Use case describes what the auto-teller does in that situation Why are use cases good for brainstorming requirements? Example use case (from Fowler and Scott, UML Distilled) Use Case: Buy a Product (Have we described this behavior is a user's language?) Actors: Customer, System (Why might it a be a good idea to define actors in a case?) 1. Customer browsers through catalog and selects items to buy 2. Customer goes to check out 3. Customer fills in shipping information (address; next-day or 3-day delivery) 4. System presents full pricing information, including shipping 5. Customer fills in credit card information 6. System authorizes purchase 7. System confirms sale immediately 8. System sends confirming email to customer (Did we get the main scenario right?) Alternative: Authorization Failure (When might this happen? I.e., at what step?) 6a. At step 6, system fails to authorize credit purchase Allow customer to re-enter credit card information and re-try Alternative: Regular customer (At what step might this happen?) 3a. System displays current shipping information, pricing information, and last four digits of credit card information 3b. Customer may accept or override these defaults Return to primary scenario at step 6 Heuristics for writing use case text Avoid implementation specific language in use cases, such as IF-THEN-ELSE or GUI elements or even specific people or departments Which is better: "The clerk pushes the OK button." or: "The clerk signifies the transaction is done." The latter defers a UI consideration until design. Write use cases with the user's vocabulary, the way a users would describe performing the task Use cases never initiate actions; actors do. Actors can be people, computer systems or any external entity that initiate an action. A use case interaction produces something of value to an actor. Create use cases and requirements incrementally and iteratively Start with an outline or high-level description Work from a problem statement and statement of work (scope) Then broaden and deepen, then narrow and prune Use Case exercise Write a use case for withdrawing cash from an ATM machine Assume customer has already logged into the ATM with PIN and sees menu Use Case: Withdraw cash Actors: Customer, ATM 1. Customer selects Withdraw from menu 2. ATM lists customer's accounts to choose from 3. Customer chooses an account 4. ATM ask customer for an amount to withdraw 5. Customer specifies an amount 6. ATM subtracts this amount from the specified account 7. ATM tells machine to disburse requested amount of cash Alternative: Unit not $20s 5a. At step 5, customer specifies an amount not divisible by 20.00 Allow customer to re-enter amount and repeat step 5 Alternative: Insufficient funds 6a. At step 6, amount requested is greater than amount in specified account Inform customer and go to step 5 Now, how would you model ATM deposits? More use case pointers Add pre-conditions and post-conditions in each use case: What is the state of affairs before and after the use case occurs? Why? Some analysts distinguish between business and system use cases: System use cases focus on interaction between actors within a software system Business use cases focuses on how a business interacts with actual customers or events Fowler prefers to focus on business use cases first, then come up with system use cases to satisfy them Note iterative approach in developing use cases, too Text and Diagrams Use case text provides the detailed description of a particular use case Use case diagram provides an overview of interactions between actors and use cases Use case diagram Bird's eye view of use cases for a system Stick figures represent actors (human or computer in roles) Ellipses are use cases (behavior or functionality seen by users) What can user do with the system? E.g., Trader interacts with Trader Contract via a Trade Commodities transaction <<include>> relationship inserts a chunk of behavior (another use case) <<extend>> adds to a more general use case Advantages of use cases What do you think? Systematic and intuitive way to capture functional requirements? Facilitates communication between user and system analyst? Text descriptions of Actors and Use Cases can supplement diagrams Diagrams can help identify objects & show state/transition flow Analysis starts with use cases Design and implementation realizes them How can use cases set up test plans? How can use cases help with writing a user manual? Drives the whole development process? How can use case help with early design of user interface prototype? Can implementation details or language be added to use cases later in the life cycle? Use cases assignment Develop a set of use cases and a use case diagram for a simple ATM (simple means you can just consider two kinds of accounts, savings and checking, and two transactions, deposits and withdrawals) Due by noon, next Tuesday, Jan 31 So, how will you do requirements gathering and specification? By Monday, January 30: email me a tentative project title, customer, team members, and tentative roles By Wednesday, February 8: 1. Write a high-level requirements specification (probably in more detail than the handout) 2. Write uses cases describing system behavior 3. Develop & justify preliminary estimates (person-hours) for class design, implementation, and testing 4. Assess any risks associated with the project 5. Discuss your approach to the software life cycle and its implications for your project and team organization ...
View Full Document

Ask a homework question - tutors are online