CHAPTER 11 REQUIREMENTS

Lecture Software Engineering CHAPTER 11 REQUIREMENTS Lecture Software Engineering Topics Determining What the Client Needs Overview of the Requirements Workflow Understanding the Domain The Business Model Initial Requirements Initial Understanding of the Domain: The Art Dealer Initial Business Model: The Art Dealer Initial Requirements: The Art Dealer Continuing the Requirements Workflow: The Art Dealer The Test Workflow: The Art Dealer The Classical Requirements Phase Rapid Prototyping Lecture Software Engineering Topics Human Factors Reusing the Rapid Prototype CASE Tools for the Requirements Workflow Metrics for the Requirements Workflow Challenges of the Requirements Workflow Lecture Software Engineering Reference Schach, S.R. (2010). Object-Oriented and Classical Software Engineering, Eighth Edition. McGraw-Hill, ISBN: 978-0-07-337618-9.

Determining What the Client Needs Primary objective of requirements workflow: Determine what must the new product be able to do Misconception: Determine what software the client wants Real objective: Determine what software the client needs Problems Many clients do not know what they need Clients may have difficulties with accurately conveying the ideas Clients may not appreciate what is going on in their organization Software is complex Difficult enough for a system analyst to visualize a software product Far worse for a client Overview of the Requirements Workflow First step of requirement workflow: Gain an understanding of application domain (environment in which product operates) E.g., banking, space exploration, automobile manufacturing Once developers understand domain: Developers build business model Use UML diagrams to describe the client s business processes Business model used to determine client s initial requirements Then iteration is applied Until development team is satisfied with the set of requirements Requirements engineering What is performed during requirements workflow Requirements elicitation (requirements capture) Process of discovering the client s requirements Requirements analysis Process of refining and extending the initial set of requirements Understanding the Domain To elicit the client s needs: Members of requirements team must be familiar with application domain (general area in which the target product is to be used) Initial task of each member of requirements analysis team: Acquire familiarity with application domain Unless already has experience Important to use correct terminology when communicating with client and potential users: To avoid misunderstanding One approach is to construct a glossary A list of technical words used in domain, together with their meanings Initial entries are inserted while team learns application domain Updated whenever new terminology is encountered Printed out every so often and distributed or downloaded to a PDA Understanding the Domain Advantages of glossary Reducing confusion between client and system analysts Lessening misunderstanding between development team members Once requirements team has acquired familiarity with domain: Next step is to build a business model

The Business Model Business model Description of business processes of an organization Provides an understanding of client s business as a whole Developers can advise client as to Which portions of business to computerize or To incorporate extensions and make modification To build a business model A systems analyst needs to obtain a detailed understanding of various business processes Processes are refined (analyzed) in greater detail A number of techniques can be used to obtain information needed: Primarily interviewing The Business Model Interviewing Members of requirements team meet with members of client organization Until they are convinced they have elicited all relevant information: From client and future users of target software product There are two basic types of questions Closed-ended question: Requires a specific answer E.g., how fast a response time is required Open-ended question: Asked to encourage speaking out E.g., why is current software product unsatisfactory Two basic types of interviews Structured interview Pre-planned questions, frequently closeended The Business Model Unstructured interview Starts with one or two prepared close-ended questions Subsequent questions in response to the answers Likely to be open-ended Not a good idea if interview is too unstructured Unlikely to yield much knowledge Wide-ranging answers within context of specific information needed Conducting a good interview is not always easy Interviewer must be fully familiar with application domain No point in interviewing if interviewer has already made up mind regarding client s needs Interviewer must approach every interview with intention of listening carefully, while suppressing preconceived notions The Business Model After interview is concluded Interviewer must prepare a written report: Outlining results of interview Provide a copy to the person interviewed: Clarify certain statements or add overlooked items Other Techniques Interviewing: Primary technique for obtaining information for business model Some other techniques may be used in conjunction with interviewing One method is to send a questionnaire to relevant members of client organization Opinions of large number of people can be determined Written answers may be more accurate than verbal responses

The Business Model Since pre-planned: Cannot pose questions in response to answers Another method is examining forms used by business E.g., information from various fields on a form Operating procedures, job descriptions User manuals of software products in use Client documents can be a valuable source of information Another method is by direct observation of users Members of requirements team observing and writing down actions of employees while performing their duties A modern version is to set up video cameras within workplace With prior written permission of those being observed Record exactly what is being done Can take a long time to analyze the tapes Difficulty with employee acceptance Possible risks: Potential to annoy or anger employees The Business Model Use Cases Model Set of UML diagrams that represent one or more aspects of software product Use case Primary UML diagram used in business modeling Use case models an interaction between software product and its users Use case shows interactions between software product and environment in which it operates 11.1 The Business Model Actor User of product: Member of world outside product Representations Actors are represented by UML stick figures (e.g., customer and teller of a banking software product) Business activities represented by label inside oval (e.g., use case for withdraw money) One actor can participate in multiple use cases An actor need not be a human Another software product can be an actor E.g., e-commerce information system interacting with a credit company information system The Business Model Overlapping actors E.g., hospital software product Actor medical staff with two specialization (physician and nurse) 11.2

Initial Requirements Initial requirements are drawn up based on initial business model As the understanding is refined of domain and business model Requirements are refined Requirements are dynamic There are frequent changes Handling the changes Maintain a list of likely requirements With use cases agreed by development team And approved by the client Object-oriented paradigm is iterative Glossary, business model, and requirements could change Requirements fall into two categories functional Nonfunctional Initial Requirements Functional requirement Specifies an action that target product must be able to perform Often expressed in terms of inputs and outputs Handled during requirements and analysis workflow Nonfunctional requirement Specifies properties of target product Platform constraints, response time, reliability May have to wait until design workflow Detailed knowledge may be needed Unavailable until requirements and analysis workflow are completed Whenever possible handled during the requirements and analysis workflow Initial Understanding of the Domain: The Art Dealer Case study of a software product for an art dealer to assist in buying and selling paintings Essential to obtain domain knowledge Information about paintings Information about the art business Medium Material with which artwork was painted Oil-based paint, water-based paint, pencil, pastel Subject person (portrait), nature (landscape), inanimate object (still life) Quality Masterpiece (undoubted excellence) Masterwork (inferior painting by an artist with a masterpiece) Other painting (neither masterpiece, nor masterwork) Information is put into glossary Initial Understanding of the Domain: The Art Dealer

Initial Business Model: The Art Dealer Necessary to interview art dealer to obtain detailed information about every aspect of business A management consultant analyzed business records and concluded that art dealer is overpaying for paintings Advised to acquire a software product: Running on a laptop computer Use to determine the maximum price to pay for a painting: Management consultant derived an algorithm that software product should use Software product should detect new trends in art market as soon as possible: If trend of higher prices, buying before others notice the trend Software product should produce reports: On purchases and sales Initial Business Model: The Art Dealer Initial business model can be built Three business activities Buy painting Sell painting Produce reports Three use cases Use cases are combined into the use case diagram A UML diagram that reflects two or more use cases Next, use cases are annotated Initial use case descriptions are added Next, initial requirements are drawn up Initial Business Model: The Art Dealer Initial Business Model: The Art Dealer

Initial Business Model: The Art Dealer Initial Requirements: The Art Dealer Decide which of use cases are also requirements of software product Resulting initial requirements are refined adding, modifying, and removing requirements All three use cases from initial business model will be initial requirements All three processes will be automated in target product Initial descriptions are replaced by new descriptions The vagueness of descriptions is a consequence of iterative nature of object-oriented paradigm Initial Requirements: The Art Dealer Initial Requirements: The Art Dealer

Initial Requirements: The Art Dealer Continuing the Requirements Workflow: The Art Dealer More details need to be acquired for next iteration Data for each painting: Determined by examining relevant documentation (current manual records) Description of a painting Artist, title of work, date of work Classification, dimensions, medium, subject Date of purchase, seller information Actual purchase price Target selling price (e.g., 2.15 times purchase price) Maximum purchase price determined by algorithm Date of sale, buyer information, actual selling price Maximum price algorithm is developed by management consultant Continuing the Requirements Workflow: The Art Dealer Three types of reports Current reports are examined Needs are determined Data to include, sorting, averages Detecting new trends in art market When higher prices are consistently paid for an artist s work Buy up painting by that artist A report is required: Artists whose work has been sold by art dealer at a price exceeding target selling price Requirements team updates use case descriptions: Incorporating these details Continuing the Requirements Workflow: The Art Dealer

Continuing the Requirements Workflow: The Art Dealer Continuing the Requirements Workflow: The Art Dealer Continuing the Requirements Workflow: The Art Dealer Continuing the Requirements Workflow: The Art Dealer

Continuing the Requirements Workflow: The Art Dealer The Test Workflow: The Art Dealer While performing requirements workflow: Members of requirements team have to continually check their work Artifacts of requirements workflow need to be checked by members of the SQA group: Test workflow is performed Requirements team forgot to include a use case for updating a fashionability coefficient Current fashionability of an artist Can vary from month to month A new use case and its description are added Changes and extensions may have to be made at any time The Test Workflow: The Art Dealer The Test Workflow: The Art Dealer

The Classical Requirements Phase On one hand, there is no such a thing as object-oriented requirements Aim is to determine client s needs Requirements workflow has nothing to do with how product is to be built Analogous to no such a thing as an object-oriented user manual On the other hand, entire approach described, is object oriented in nature It is model oriented Use cases, together with their descriptions, form the basis of requirements workflow Modeling is the essence of object-oriented paradigm Modeling in general is not part of the classical paradigm: UML in particular The Classical Requirements Phase Classical requirements phase Starts with requirements elicitation Followed by requirements analysis Next step is to draw up a list of requirements Usual step after that is to build a rapid prototype Implements key functionality underlying those requirements Client and future users experiment with rapid prototype: Until rapid prototype exhibits key functionality Building a rapid prototype for the product as a whole is not part of object-oriented paradigm. Strongly advisable to build a rapid prototype of user interface Rapid Prototyping Rapid prototype Hastily built software that exhibits key functionality of target product Include: Input screens and output reports Not included: Error checking, file updating, and complex computations Rapid prototype reflects the functionality client sees: Omits hidden aspects Utilization of rapid prototype Client and intended users experiment with prototype Development team members observe and take notes Users provide feedback: How rapid prototype satisfies needs and areas that need improvement Developers change rapid prototype: until both sides are convinced Rapid Prototyping Rapid prototype used as basis for drawing up specifications Important aspects of rapid prototype Rapid: Built as quickly as possible, enabling client and developers to agree on product Built for change: If first version not acceptable, second version is built Languages used for rapid prototyping Fourth-generation languages (4GL) Interpreted languages (Smalltalk, Prolog, Lisp) Popular rapid prototyping languages of today (HTML, Perl) Concerns about maintainability of certain interpreted languages: Irrelevant from viewpoint of rapid prototyping Rapid prototyping is particularly effective when developing the user interface to a product

Human Factors Encouraging users to experiment with human-computer interface (HCI) greatly reduces risk that finished product has to be altered Experimentation can help achieve user-friendliness User-friendliness Ease with which human beings can communicate with software product Menu-driven products were introduced HCIs employ graphics Components of a graphical user interface (GUI) Windows, icons, pull-down menus Standards such as X Window have evolved Point-and-click selection is now the norm HCI designers must consider human factors Size of letters, capitalization, color, line length, number of lines Human Factors Menu-driven system thoughtfully designed Allowing user to change a previous selection: Without having to start again Product can be used by people with varying degree of experience: Different sets of HCI Benefits of taking into account human factors during design of an HCI Reduced learning times Lower error rates Uniformity of HCI appearances Across a product or a group of products Results in users intuitively knowing how to use a screen Taken into account by designers of Macintosh software Essential that a rapid prototype of HCI of every product be constructed Reusing the Rapid Prototype Alternative to discarding rapid prototype: Develop and refine the rapid prototype Generally unwise Advantage Fast software development Disadvantages Similar to code-and-fix approach Code difficult and expensive to maintain Lower performance of rapid prototypes One way of ensuring that the rapid prototype is discarded Building rapid prototype in a different language E.g., rapid prototype in HTML, product specified to be in Java Refining portions of rapid prototype Computer generated portions E.g., CASE tools for screen generation and report generation Reusing the Rapid Prototype Management decides on portions before rapid prototype is built Portions have to pass same quality assurance tests To ensure that quality of code is sufficiently high: Rapid prototype has to be built somewhat more slowly

CASE Tools for the Requirements Workflow A drawing tool that enables user to draw relevant UML diagrams with ease Major strengths Easier to change a diagram while iterating than to redraw by hand The details of the product are stored in the CASE tool: Documentation always available and up to date Weakness Not always user-friendly: Lots of functionality and steep learning curve Almost impossible to program a computer to draw UML diagrams that are as aesthetically pleasing as diagrams drawn by humans Considerable amount of time tweaking a diagram in a tool Many CASE tools are expensive: A number of open-source tools are available CASE Tools for the Requirements Workflow Overall: Strengths of CASE tools outweigh weaknesses Many classical graphical CASE workbenches and environments have been extended to support UML diagrams System Architect Software through Pictures Object-oriented CASE workbenches and environments IBM Rational Rose Together Open-source ArgoUML Metrics for the Requirements Workflow Key feature of requirements workflow: How rapidly requirements team determines client s real needs A useful metric: A measure of requirements volatility Keeping a record of how frequently the requirements change Management determining rate at which team converges on requirements Can be applied to any requirements elicitation technique Another metric: Number of requirements that change during the rest of software development process Recorded whether change initiated by the client or developers If a large number of changes initiated by developers: Process for requirements workflow should be reviewed If client makes repeated changes: Warning client about effects of the moving target problem Future changes should be held to a minimum Challenges of the Requirements Workflow Potential problems and pitfalls are associated with requirements workflow Essential to have the wholehearted cooperation of potential users Feeling threatened by computerization Concerns about potential impacts of the software product Another challenge: Ability to negotiate Scaling down what the client wants A product that does everything is not reasonable Arriving at a compromise among managers at client organization regarding functionality: Managers requesting features for their own group Another challenge: In many organization, individuals who possess the information that requirements team needs to elicit lack the time to meet for in-depth discussions

Challenges of the Requirements Workflow Team must inform client to decide what is important Developers may have to withdraw if no solution Finally: Flexibility and objectivity are essential for requirements elicitations Should approach each interview with no preconceived ideas Should never make assumptions about requirements