1 / 25

Ch 10: Requirements

Ch 10: Requirements. CSCI 4320. Requirements Workflow. Acquire basic understanding of the application domain ( banking, automobile manufacturing ) Identify Customer Impact Identify Constraints ( deadlines, costs, existing hardware, software ) Written in Language of Client

angeni
Download Presentation

Ch 10: Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ch 10: Requirements CSCI 4320

  2. Requirements Workflow • Acquire basic understanding of the application domain (banking, automobile manufacturing) • Identify Customer Impact • Identify Constraints (deadlines, costs, existing hardware, software) • Written in Language of Client • Problem: Sometimes the client does not know what is going on in his organization. GOAL: Assist client in gaining understanding of system

  3. Requirements Workflow • Gain an understanding of the application domain (or domain, for short) • The specific environment in which the target product is to operate • Build a business model • Model the client’s business processes • UML Diagrams (use cases) • Use the business model to determine the client’s requirements Iterate the above steps

  4. Understanding the Domain • Maintain a glossary of technical words used in the domain, together with their meaning

  5. Building a Business Model • Business Model – Description of business processes of an organization • Banking ( accepting deposits, loaning money, making investments)

  6. Gathering Information • Interviewing is the Primary Technique • Open-ended Questions • Encourage person to speak out • Why is your current software unsatisfactory? • Closed-ended Questions • requires specific answer • How many employees? • Structured Interview • Preplanned questions, (frequently closed-ended) • Unstructured Interview • Questions are posted in response to answers received

  7. Gathering Information • Interviewing is not easy • Interview must be familiar with application domain • Interviewer must not have already made up his mind regarding client needs • Listen carefully, suppress preconceived notions • After interview prepare a written report outlining the results of the interview • Let interviewee see the report

  8. Gathering Information • Questionnaire • Many individuals can participate • Examine Forms In Use • Various fields shed light of importance of information in use • Direct Observations • Modern Version :Videotape camera • Long time to analyze tapes • Employees may see it as an invasion of privacy

  9. Building A Model • Model • Set of UML diagrams that represent system functions • Use Cases • Model interaction between the software product and the users of the software (actors) • Show interaction between software product and the environment • Stick Figures

  10. 10.4.3 Use Cases Example: Figure 10.1

  11. Identifying Actors • An actor is a member of the world outside the software product • User • Initiator • Someone who plays a critical part in the user case

  12. Identifying Actors (cont) Actors are not necessarily Human. They can be software products. • When building an E-Commerce Information System you should allow purchasers to pay with credit cards • Your system interacts with the credit card company information system. Thus, the credit card company information system is an actor

  13. Identifying Actors (cont) • Potential Problem • Overlapping Actors • Too Specific Example: Don’t prepare different use cases for Physicians and Nurses when one use case for Medical Staff is appropriate.

  14. 10.5 Initial Requirements • The initial requirements are based on the initial business model • Then they are refined • The requirements are dynamic — there are frequent changes • Maintain a list of likely requirements, together with use cases of requirements approved by the client

  15. Initial Requirements (contd) • There are two categories of requirements • Afunctional requirement specifies an action that the software product must be able to perform • Often expressed in terms of inputs and outputs • A nonfunctional requirement specifies properties of the software product itself, such as • Platform constraints • Response times • Reliability

  16. Initial Requirements (contd) • Functional requirements are handled as part of the requirements and analysis workflows • Some nonfunctional requirements have to wait until the design workflow • The detailed information for some nonfunctional requirements is not available until the requirements and analysis workflows have been completed

  17. Rapid Prototype • Hastily built software • Exhibits key functionality of the target product • Omits hidden aspects such as file updating • Effective when developing user interface • Clients can experiment and give feedback to developers • Must be built for change

  18. Human Factors If screens are confusing or product is difficult to use software product will not be used. • Human Computer Interface (HCI) • User Friendliness • Ease for humans to communicate with software • Menus • Graphical User Interface (windows, icons, pull-down menu)

  19. Human Factors (cont) • Size of letters • CAPITALIZATION • Color • Line length • Number of lines on screen

  20. Human Factors (cont) • Limit # of Preceding Menus • Lengthy sequence of menus to reach goal makes users angry • Design for different skill levels • Short cuts for advanced • As users become more familiar with product, streamline screens • Uniformity of appearance reduces learning time

  21. Reusing the Rapid Prototype • Discard the prototype – don’t fall into code-and-fix model • Resulting code of hurriedly put together prototype can be confusing and is difficult to maintain • Use a different language from that of product

  22. Reusing the Rapid Prototype • When is it permissible to reuse portions of the rapid prototype? • When CASE tools such as screen generators and report generators have been used. (Ex. Software Through Pictures Section 5.5, pg 123) • Management decides BEFORE the rapid prototype is built to reuse portions • High quality code passes design and code inspections

  23. CASE Tools for the Requirements Workflow • Drawing tools to draw diagrams • Documentation can be kept up-to-date • Weakness • Sometimes CASE Tools are not user friendly • Spend time tweaking layouts • ArgoUML • Open Source CASE tool for drawing UML diagrams

  24. Metrics for The Requirements Workflow • The goal is to rapidly determine client’s needs • How frequently do the requirements change? • During requirements workflow • During the rest of the software development process • Who initiated the change? (client, developer) • Client: moving target possibility • Developer: need for revising requirements elicitation

  25. Challenges of the Requirements Workflow • Wholehearted cooperation of potential users • job security • misleading information • Negotiation • Persuade client to accept less that what he wants (compute cost and benefits) • Compromise among managers regarding functionality • Time for in-depth discussions • Flexibility and Objectivity • Interviewer should not make assumptions about requirements

More Related