Interviews q q q Personal interviews are perhaps

Interviews q q q Personal interviews are perhaps most extensively used especially in the case of project software development Requirement engineer discusses the system with different stakeholders and buildup an understanding of their requirements Three types of interviews q Close ended q Where the requirement engineer look for answers to a predefined set of questions q Open ended interviews q Where there is no predefined agenda and the requirements engineer discusses in an open ended way what stakeholders want from the system q Semi structured interviews q A requirement engineer starts with a predefined set of questions, but as different issues arises, they are discussed in an open ended way

Requirements Elicitation Techniques

Steps for conducting interviews q Establish rapport q q Stay in scope q q To begin an interview, introduce yourself if the attendees don’t already know you, review the agenda, remind attendees of the session objectives, and address any preliminary questions or concerns attendees have. As with any elicitation session, keep the discussion focused on its objective. Even when you are talking with just one person or a small group, there’s a chance the interview will go off topic. Prepare questions q Prepare for interviews by drafting any materials you can beforehand, such as a list of questions to guide the conversation. Draft materials will give your users a starting point to think from.

Steps for conducting interviews q Suggest ideas q q Rather than simply transcribing what customers say, a creative Requirements Engineer proposes ideas and alternatives during elicitation. Sometimes users don’t realize the capabilities developers can provide Listen actively q Practice the techniques of active listening (leaning forward, showing patience, giving verbal feedback, and inquiring when something is unclear) and paraphrasing (restating the main idea of a speaker’s message to show your understanding of that message).

Goal Modeling

Goal § § A goal is an objective the system under consideration should achieve. Goals may be formulated at different levels of abstraction, ranging from high-level, strategic concerns § Transport passengers safely for a train transportation system § provide ubiquitous cash service for an ATM network system To low-level, technical concerns § “keep doors closed when moving” for a train transportation system § “card kept after 3 wrong password entries” for an ATM system Goals also cover different types of concerns: § functional concerns associated with the services to be provided, § nonfunctional concerns associated with quality of service –such as safety, security, accuracy, performance, and so forth.

Goals for a Restaurant § § The owner/manager § wants to make a profit, and to have a business that is not too much trouble to run. § This means, for example, having a good cook, efficient staff, and low maintenance and running costs. The cook § wants good pay and to develop a reputation so he can have a successful career as a famous chef. § That means he wants the restaurant to enable him to prepare delicious and distinctive food. § He doesn’t want any problems with hygiene or staff absence. That in turn means he needs top equipment, well -trained staff, the best raw materials and, crucially, a large enough budget.

Goals for a Restaurant § § The customers § who eat in the restaurant want good food and value for money; they want a predictable price, good service and an enjoyable ambience. § They certainly don’t want to get food poisoning, so safety is important to them. The suppliers § of food and other materials want to be paid, promptly and in full. The local council’s public health department § want to see that hygiene rules are obeyed. The taxman § wants to know that the proper amounts of tax are being paid by the business.

“Goals List” of different stakeholders in restaurant

Goal model for “increase profit” goal

Support and conflict among restaurant stakeholders’ goals

Goal model for fulfilling books order

Goal model q q q Goal model generally incorporates a set of goals or more precisely hard goals, a set of tasks and optionally a set of soft goals A goal represents a condition, outcome, or state of the world that is to be achieved A task indicates a certain activity that an actor performs to fulfill a goal q Tasks specify (in full or in part) how particular goals will be fulfilled and hence they form the leaf nodes of the goal tree, where each task's parent is the goal that it contributes to realizing. The goals at intermediate levels (internal nodes) express portions of the system's functionality or alternatives for providing that functionality. Each goal may be refined into one or more subgoals via ANDdecomposition, where a goal is divided into subgoals that must all be satisfied in order to fulfill the original goal, or ORdecomposition, where each subgoal indicates an alternative way to satisfy the original goal.

Why are goals needed? q q Achieving requirements completeness q Goals provide a precise criterion for sufficient completeness of a requirements specification; the specification is complete with respect to a set of goals if all the goals can be proved to be achieved from the specification Avoiding irrelevant requirements q A requirement is relevant with respect to a set of goals if its specification is used in the proof of one goal at least Explaining requirements to stakeholders q Requirement appears because of some underlying goal which provides a base for it. A goal refinement tree provides traceability links from high-level strategic objectives to low-level technical requirements. Requirements readability q Goal refinement provides a natural mechanism for structuring complex requirements documents for increased readability

Use case modeling q q q Use cases were developed originally to support requirements elicitation and now incorporated into the UML. Each use case represents a discrete task that involves external interaction with a system. Actors in a use case may be people or other systems. A use case is shown as an ellipse with the actors involved in the use case represented as stick figures Represented diagrammatically to provide an overview of the use case and in a more detailed textual form.

Problem statement § § The Online Shopping system facilitates the customer to view the products, inquire about the product details, and product availability. It allows the customer to get register in order to purchase products. The customer can search products by browsing different product categories or by entering search keywords. Customer can place order and pay online. There are two acceptable payment methods. These are (1) pay by credit card and (2) pay by Pay. Pal. The system provide service to seller to place the products for selling. The seller creates account to become the member and places his products under suitable product category. The systems allows the administrator to manage the products. It facilitates the administrator to modify the existing products categories or to add new products categories. The system facilitate site manager to view different reports including (1) order placed by customers, (2) products added by sellers, and (3) accounts created by users.

Stakeholders and associated use cases q Customer q q q view the products inquire about the product details inquire about products availability get register purchase products search products q q q by category by keyword pay online q q pay by credit card pay by paypal

Stakeholders and associated use cases q q q Seller q place the products for selling q create account q place products product category Administrator q Manage products q modify the existing products categories q add new products categories Site manager q view order placed by customers q view products added by sellers, q view accounts created by users.

Use case examples

USE CASE 5 Buy Goods Goal in Context Buyer issues request directly to our company, expects goods shipped and to be billed. Scope & Level Company, Summary Preconditions The company knows Buyer, their address, etc. Success End Condition Buyer has goods, company have money for the goods. Failed End Condition Company have not sent the goods, Buyer has not spent the money. Primary, Secondary Actors Buyer, any agent (or computer) acting for the customer. Credit card company, bank, shipping service Trigger purchase request comes in. Basic Events Flow Step Action 1 Buyer calls in with a purchase request 2 Company captures buyer’s name, shipment address, requested goods, etc. 3 Company gives buyer information on goods, prices, delivery dates, etc. 4 Buyer signs for order. 5 Company creates order, ships order to buyer. 6 Company ships invoice to buyer. 7 Buyers pays invoice. Step Alternative Flow (Branching Action) 3 a Company is out of one of the ordered items: 3 a 1. Renegotiate order. 4 a Buyer pays directly with credit card: 4 a 1. Take payment by credit card (use case 44) 7 a Buyer returns goods: 7 a. Handle returned goods (use case 105) EXTENSIONS Superordinates Manage customer relationship (use case 2) Subordinates (included use cases) Create order (use case 15) Take payment by credit card (use case 44)

Use cases in the MHC-PMS involving the role ‘Medical Receptionist’

Use cases for the MHC-PMS

Hotel booking

Use case “<<include>>” example

<<include>> and <<extend>> An include relationship specifies how the behavior for the inclusion use case is inserted into the behavior defined for the base use case. An extend relationship specifies how the behavior of the extension use can be inserted into the behavior defined for the base use case.

Online Selling

Ethnography q People often find it very difficult to explain how they carry out their routine tasks and how they work together in particular situation. q q q How to tie a shoelace? Difficult to describe but easy to demonstrate process Observation is a better way of understanding this type of tasks to understand what support people need from a computer-based system Ethnography is an observational technique that can be used to understand operational processes and help derive requirements for these processes. A social scientist spends a considerable time observing and analysing how people actually work.

Ethnography q q People do not have to explain or articulate their work. Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models. For example observing workers in a bank to understand their everyday work and hence derive requirements for computer support. Ethnography studies cannot be carried out according to a formula q They are dependent on the personality of ethnographer q The type of process being studied q People involved in the process q To be effective, the ethnographer must be accepted by the people being studied q The people must feel comfortable to carry on their daily tasks in the presence of ethnographer.

Ethnography study process q q Assume that people you are studying are good at doing their jobs and look for non-standard ways of working. q These often points to the efficiencies which has been introduced through individual experiences It is important to spend time getting to know people involved and establish a relationship of trust. q For this reason, ethnography is best carried out by an external organization. Detailed notes of all work practices should be made during the observation and written up on regular basis. q The ethnographer must analyze the notes and draw conclusions from them. Open ended interviewing can be combined with ethnography to develop an understanding of what is going on.

Scope of ethnography q q q Requirements that are derived from the way that people actually work, rather than the way in which process definitions suggest that they ought to work. Requirements that are derived from cooperation and awareness of other people’s activities. Ethnography is effective for understanding existing processes but cannot identify new features that should be added to a system.

Prototyping § § A prototype of a system is an initial version of the system which is available early in the development process. In software systems, prototypes are more often used to help elicit and validate the system requirements. An essential requirement for the prototype is that it should be possible to develop it quickly so that it can be used during the development process. This means that § § § Not all functionality will be included Normal mechanism of management and quality assurance may be ignored Non functional requirements such as reliability, performance, security are ignored

Throw-away prototype § § The throw-away prototype should be discarded when the final system has been developed. Throw-away prototype is used to help elicit and analyze system requirements The requirements which should be prototyped should be those which are hardest to understand. Requirements which are well understood need not to be implemented by the prototype

Evolutionary prototype § § § Evolutionary prototyping is an approach to software system development where a system with limited functionality is made available to user early in the development process. This system is then modified and extended to produce the final system. Evolutionary prototype is intended to deliver a workable system quickly to the customer. Therefore, the requirements which should be supported by the initial versions of this prototype are those which are well under stood and which can deliver useful end-user functionality.

Benefits of prototyping § § § The prototype may help to establish the overall feasibility and usefulness of the system before high development costs are incurred A closer match to user’s real needs Prototyping is an effective way of developing system user interfaces. Improved system usability Improved maintainability

Problems associated with prototyping § Development cost § § Extended development schedule § § § Development cost of prototyping depends on the type of system being developed. It may range from few person days for small systems to several person weeks. In some cases, developing a prototype will cause the development schedule to be extended and final delivery date of the product is delayed. However if the product delivered is more suited to customer needs that is not necessarily a problem Incomplete prototyping § Prototyping can only simulate the system functionality. It can mislead the customer as they may think that the system as a whole will have the same performance

The process of prototype development Objectives: (1) To develop a system to prototype the user interface, (2) To develop a system to validate functional system requirements etc Functionality: Relax non-functional requirements such as response time and memory utilization, standards of reliability and program quality Evaluation: Provision must be made for user training; prototype objectives should be used to derive a plan for evaluation; Users need time to become comfortable with a new system and to settle into a normal pattern of usage