1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. The process of prototype development

11. 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

12. Goal model for “increase profit”

13. Goals of different stakeholders in restaurant

14. Stakeholder goals support

15. Goal model for fulfilling books order

16. 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.

17. 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

18. 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

19. 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

20. 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 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.

21. 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.

22. 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