Ch 10: Requirements CSCI 4320

Requirements Workflow 1.Acquire basic understanding of the application domain (banking, automobile manufacturing) 2.Identify Customer Impact 3.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

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

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

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

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

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

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

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

Use Cases Example: Figure 10.1

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

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

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.

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

Initial Requirements (contd) There are two categories of requirements A functional 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

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

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

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)

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

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

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

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

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

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

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