Requirements Elicitation Elicitation q The Dictionary meaning of

Requirements Elicitation

Elicitation q The Dictionary meaning of the term ‘‘elicit’’ is to ‘‘draw forth or bring out’’ q Elicitation is first hand collection of information from individuals who are directly concerned with the project. It is from primary sources. Primary sources include end users, experts. q Gathering is an indirect collection of information from sources other than human beings. It is from secondary sources. Secondary sources include documents, existing applications, and standards and guidelines.

Requirement Elicitation q q q It is the first stage in building an understanding of the problem the software is required to solve. It is fundamentally a human activity and is where the stakeholders are identified and relationships established between the development team and the customer One of the fundamental principles of a good requirements elicitation process is that of effective communication between the various stakeholders. This communication continues through the entire Software Development Life Cycle (SDLC) process with different stakeholders at different points in time. Before development begins, requirements specialists may form the channel for this communication.

Requirements Sources

Discovering Stakeholders q q q Requirements ultimately begin and end with people – stakeholders Constructing an onion model is a good way to start to understand document the stakeholder structure of your project Another starting point may be an organisation chart, as long as you don’t overlook stakeholders outside the organisation

Onion model: Product centric view

Operational Stakeholders within ‘The System’ q q q The innermost ring of the onion (around its solid centre) is ‘the system’. This means the people, procedures and products that together deliver results to the world outside. Notice that ‘the system’ is not the same as a product, a service, The people who form part of the system around a product or service are the operational stakeholders: they take part in day-to-day operations. Typical systems contain several operational roles In a complex system, there may be hundreds of different operational roles.

Stakeholders in the Containing System and Wider Environment Beneficiaries: Who’s it for? The man who pays the piper calls the tune.

System beneficiaries q Functional Beneficiary In fact, the service is for them. q Other beneficiaries q politicians

Regulators q q q Regulators q Financial correctness q Food q Medicine q Railways Regulations Standards and regulations can be seen as reusable sets of requirements that are shared between all systems in a domain. q Legislations: Laws passed by the parliament q International standards: Imposed by bodies such as International Standard organization q national standards: imposed by general standards bodies such as the British Standards Institution q industry ‘best practice’ and ‘guidance: which are often essentially mandatory within an industry, especially where safety is concerned q company standards: imposing a software development process.

Interfacing stakeholder q q Almost every system has significant interfaces to other systems, services or businesses For example, many devices such as laptop computers and mobile phones have a Bluetooth short -range radio interface, allowing them to exchange data with other Bluetooth-compatible devices. Identifying the systems or services that you need to interface to is obviously a vital step towards creating the right requirements and the right product. The project or organisation responsible for the other end of each interface is an important stakeholder in your project.

Negative Stakeholders q q Negative stakeholders range in attitude from peaceful opposition to active aggression. for example, writing letters to the government and collecting signatures to oppose the construction of a road, airport, shopping centre or power station that threatens to destroy assets valued by the stakeholders. q historic buildings, q the natural environment and wildlife q existing jobs and businesses q Safety, peace, quietness, privacy They may threaten or cause harm to a project, intentionally or incidentally. Your competitors may not wish your project to succeed, but they will generally stay within the law in their opposition to it.

Negative Stakeholders q q Security threats also come in many shapes: q thieves, thug, hackers, irritated employees, criminal gangs using viruses and malware, military enemies q Thieves and hackers may be opportunistic, rather than intentionally hostile. The others are, actually hostile by intention. For military systems, the enemy is a key stakeholder. He may use any means to confuse, disrupt, deceive or destroy. Countering these threats leads to many of the requirements on military equipment, for qualities such as data integrity, confidentiality and survivability the public are becoming concerned about data protection for reasons of privacy and financial security.

Sponsor and Champion q q q Without a sponsor your project will be short lived. In both commercial companies and public service, money is generally in shorter supply than ideas for how to spend it. Therefore, departments usually compete for resources Any project that receives funding may be watched jealously for signs of weakness so that it may be killed off and its funds appropriated for something else. The sponsor provides development funding for a project. The Champion has to be someone with enough power in the organization to protect the project against ‘political’ threats

How to begin “Identifying Stakeholders” q by asking your sponsor or client; q by examining what is and what isn’t shown on an organization chart; q with a template such as the ‘onion model’; q by comparison with similar projects;

From your Sponsor or Client q q A natural place to start is your sponsor. Ask them who the other stakeholders are. Meet those people and ask them the same question, and so on. This would be an ideal approach but for one thing: project people may only lead you to people they know, within a tight group. This, is perhaps, a particular danger within a large organisation.

With a Template such as the Onion Model q The onion model or an equivalent list of typical project stakeholders can help to counter closed-group thinking. q For each icon on the diagram, ask: ‘ q Add new icons if necessary, and label them with their roles. q Draw arrows between the role icons, and label these for each interaction or influence.

Possible roles in a project • Operational roles – – – Normal operation Maintenance Support Training Planning, scheduling Control, management • Beneficiaries – Functional beneficiaries – Financial beneficiaries • Developers – – – Requirements analyst Designers Programmer Tester Technical writer • Expert/ consultant – – Safety engineer Security engineer Legal opinion Translator, cultural advisor • Regulator – Parliament – Government departments – Standard bodies • Purchaser – – Internal customer Project sponsor Marketing Product owner • Interfacing roles – Owner of interfacing system (sharing data etc. )

Identifying Stakeholder by comparison with similar projects q If you have access to people who have experience of similar projects, ask them for their list of stakeholders, or get them to look for gaps in your list.

Managing Your Stakeholders q Managing stakeholders q keep track of your dealings with stakeholders, q analyze influences of stakeholders on your project, q Prioritize your activities accordingly

Keep track of each stakeholder Stakeholders are the people who have influence on your project. So, it’s vital that you pay attention to them q At the very least, you need to know q q who they are, what they want, and whether they have agreed to the requirements. q each stakeholder group or individual q informed as the project proceeds. It is rarely possible to meet everyone’s expectations. q By providing periodic project status updates q q manage people’s expectations and improve the likelihood of project success

Keep track of each stakeholder

Analyzing Influences q The consumer audience q Competitors q The public q Company’s financial beneficiary q The product manager

Video game development project: different influences

Influence matrix

Requirements Elicitation Techniques

Elicitation Techniques q Once the requirements sources have been identified, the software engineer can start eliciting requirements information from them. It is a very difficult task q It is particularly important to understand that elicitation is not a passive activity q

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

Steps for conducting interviews 1. Planning of personal interviews q Planning involves identifying the resources required to achieve the objective. q In this case, it is the concerned executives who can provide necessary information, q time and effort required to collect the information q logistics necessary to conduct the interviews q We begin by making a list of individuals that can provide relevant and useful information. q We then estimate the clock hours needed to elicit information from each of those executives. q We also estimate the time and effort required from us to prepare for conducting the interview and the type of persons that can conduct the interview and elicit the requirements

Steps for conducting interviews 2. Study the preliminary information to understand the domain at hand q If we are already knowledgeable in the domain at hand, we may perhaps skip this step q Otherwise, study the preliminary information provided by the client and identify the gaps. q If there is no preliminary information from the client, we may study the literature available on the subject and this study could include running demos of similar products developed earlier in our organization or demos available on the Internet. q This will help us in becoming familiar with the technical terminologies of the interviewee and aid in quick understanding of the responses received in the interview. q Failures in eliciting requirements using personal interviews mainly stop from skipping this step or performing this step in a very casual manner.

Steps for conducting interviews 3. Prepare a set of questions to ask to aid in the structured elicitation of information q we need to prepare a set of questions to guide us in conducting each of the interviews effectively q Sources of questions q existing knowledge of the domain q from study of literature q demos of similar software products q Each question would elicit information about one topic at a time.

4. Prepare formats and templates to capture information efficiently

Steps for conducting interviews 5 - Fix appointments with the identified executives q Plan the session so that executives can arrange their schedule and ensure that no interruption is caused q you may need to put up a request for an appointment on the organization’s calendar system q Having an appointment also enables the executive to be prepared for the interview as well as to make the templates/formats used by the company available to you

Steps for conducting interviews 6 -Conduct the interview effectively q Obtain information about the processes being performed at the workstation q Sympathy and gentleness are required while conducting the interview. q Gently questioning to obtain the right information. q When you conclude the interview, you must have all the information q (inputs, outputs, process steps, and data items) of all processes performed by the person.

Steps for conducting interviews q 7 Capture information q Capturing information while the interview is in progress, may force you to hurry in noting down the details. It may be a good idea to use a tape recorder of some kind to capture the voice of the interview so that it can be replayed later, to capture information into the template. q q 8. Check for completeness of information using organizational checklists

Scenarios q q q A scenario is a story adapted and structured for engineering use. The purpose of a scenario is to communicate a situation, usually as it evolves through time, in a series of steps. Scenarios describe interactions of humans and products across ‘user’ and ‘system’ interfaces Scenarios are primarily useful for adding details to an outline requirements description. Once you have basic idea of facilities that the system should provide, you can develop usage scenarios around those facilities

Scenarios description q Scenarios should contain the following information q. A description of the state of the system before entering scenario q The normal flow of events in the scenario q Exceptions to the normal flow of events q Information about other concurrent activities q A description of the state of the system after completion of the scenario

Scenario for collecting medical history in Mental Health Clinic Patient Management System (MHC-PMS)

Scenario for collecting medical history in MHC-PMS