Ethnography People often find it very difficult to explain how they carry out their routine tasks and how they work together in particular situation How to tie a shoelace? Difficult to describe but easy to demonstrate process Observation is a better way of understanding this type of tasks 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 People do not have to explain 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 They are dependent on the personality of ethnographer The type of process being studied People involved in the process To be effective, the ethnographer must be accepted by the people being studied The people must feel comfortable to carry on their daily tasks in the presence of ethnographer

Ethnography study process Assume that people you are studying are good at doing their jobs, and look for non-standard ways of working 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 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 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 Requirements that are derived from the way that people actually work, rather than the way in which process definitions suggest that they have 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 those 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 proposed to deliver a workable system quickly to the customer Therefore, the requirements which should be supported by the initial versions of this prototype 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 acquired To closer match to user’s real needs To develop system user interfaces effectively To improve system usability To improved maintainability

Problems associated with prototyping Training cost both for developer and customer Development cost Development cost of prototyping depends on the type of system being developed Extended development schedule In some cases, developing a prototype will cause the development schedule to be extended and final delivery date of the product is delayed 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

Goals A goal is an objective the system under consideration should achieve Goals may be formulated at different levels of abstraction, from high-level, strategic concerns e.g Transport passengers safely for a train transportation system provide 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 nonfunctional concerns (safety, security, accuracy, performance) GORE Guided tour

Goal model for “increase profit”

Goals of different stakeholders in restaurant

Stakeholder goals support

Goal model for fulfilling books order

Goal model 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 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 AND-decomposition, where a goal is divided into subgoals that must all be satisfied in order to fulfill the original goal, or OR-decomposition, where each subgoals indicates an alternative way to satisfy the original goal.

Why are goals needed? Achieving requirements completeness 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 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 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. In particular, for business application systems, goals may be used to relate the software-to-be to organizational and business contexts Requirements readability Goal refinement provides a natural mechanism for structuring complex requirements documents for increased readability

Elicitation in Testing Projects Testing projects differ from other types of development projects The software is already developed. The objective of the project could be different for each testing project. To uncover all hidden defects To certify a product as defect-free, virus-free, or malware-free To benchmark a product in comparison with other comparable products To accept software, from a vendor and start using it

So what sort of requirements would be needed for a testing project? The type of tests to be conducted as part of the testing project Information for planning the specified tests Information for designing the test cases Information for pass/fail decisions Process for ensuring the quality of the testing process Defect reporting and fixing strategy Constraints of time, budget etc. Progress reporting mechanisms

Elicitation in Software Maintenance Projects Software maintenance work may be carried out in-house or it could be outsourced. When outsourced, the software maintenance project would have an overall contract for the project comprising of the rates, time booking, process for resolution of maintenance work requests, prioritization rules and so on. each individual work request would be over the phone, in email or as a formal documented request. When maintenance is carried out in-house, the formal documentation is not strictly enforced Personal elicitation is almost ruled out except for telephonic elicitation.

Elicitation in Software Maintenance Projects As there is a vendor—vendee relationship involving payments, estimation and approval of estimates comes in. So, formal maintenance work requests are the mostly used form of communication. These maintenance work requests would contain detailed requirements. The vendor needs to ensure that the requirements spelled out are complete and adequate to carry out the work.

Future research directions in Requirement Elicitation research Reducing the gap between the theory and practice Developing guidelines for technique selection and managing the impacton the process Produce and publish case studies and industrial experience reports on how requirements elicitation contributed to successes and failures of projects Exploring how requirements elicitation activities relates to new and developing fields of software engineering such as agile development methodologies, and web systems