DATA GATHERING

REQUIREMENTS

First, the developing team communicates with the customers to elicit the requirements, by asking questions, demonstrating similar systems, or even developing prototypes of all or part of the proposed system.

ELICITATION

ELICITATION TECHNIQUES

interviewing group sessions observations scenarios and use cases prototyping

REQ. DEFINITION

The requirements definition document is a complete listing of everything the customer expects the proposed system to do. It represents an understanding between the customer and developer of what the customer needs or wants, and it is usually written jointly by the customer and developer.

REQ. SPECIFICATION

The requirements specification restates the requirements definition in terms appropriate for the development of a system design; it is the technical counterpart to the requirements definition document, and it is written by requirements analysts. 

Sometimes one document may serve both purposes, representing a common understanding among customers, requirements analysts and designers. But often both types of documents are needed, and the need that no information is lost or changed when reinterpreting the definition as a specification is great. 

 

Functional / Non-Functional

functional requirements describe fundamental functions of the system 

non functional requirements (NFRs) describe  –  constraints on the system (e.g. security, reliability,

portability, safety, performance) –  constraints from the application domain (e.g. interface with

existing systems in the organization)

 

CONTENT OF A REQUIREMENTS DOCUMENT

outline of the general purpose of the system description of the background and objectives of

system development (e.g. if the system is to replace an existing approach)

detailed description of characteristics of the proposed system (functional requirements)

description of the environment in which the system will operate and requirements for support, security, privacy and any other hardware or software constraints should be addressed (NFR’s)

EXAMPLE

Requirement 4.1.3.1. INITIATE TRACK ON IMAGE. Logical processing shall be done to INITIATE TRACK ON IMAGE. This shall have as input HANDOVER DATA. This shall have as output HOIQ, STATE DATA and IMAGE ID. This logical processing, when appropriate, shall identify a new instance of IMAGE. This logical processing, when appropriate, shall identify the type of entity instance as being IMAGE ON TRACK. NOTE: a request for pulses is made by entering a formal record into the HOIQ which feeds the pulse-send procedures. 

FORMAL

ALPHA: INITIATE_TRACK_ON_IMAGE.  INPUTS: HANDOVER_DATA.  OUTPUTS: HOIQ. STATE_DATA, IMAGE_ID.  CREATES: IMAGE.  SETS:IMAGE_ON TRACK.  DESCRIPTION: "(4.1.3.1) A REQUEST FOR PULSE IS MADE BY ENTERING A FORMAL  RECORD REQUEST INTO THE HOIQ WHICH FEEDS THE PULSE SENDING  PROCEDURES." 

 

CHARACTERISTIC OF REQUIREMENTS

unambiguous  complete verifiable consistent modifiable traceable usable (Macaulay 1997)

UNAMBIGUOUS

Requirements are often written in a natural language where statements can have more than one meaning. Formal requirements languages help reduce ambiguity. 

COMPLETE

The requirements documents are complete if they include all of the significant requirements, whether relating to functionality, performance, design constraints, attributes or external interfaces and conforms to the company standards. 

VERIFIABLE

An example of non-verifiable requirements is "the product should have a good human interface". An example of a verifiable requirement is "the system will respond to a user request within 20 secs of the user pressing the enter key, 80% of the time"

CONSISTENT

Three types of conflict which can occur are: different terms used for the same object: for

example, "a P45" and "a tax form" might be used to describe the same form. 

characteristics of objects conflict: for example, in one part of the requirements document, "a red light will indicate a fault", while in another part, "a blue light will indicate a fault". 

logical or temporal faults: for example, "A follows B" in one part, "A and B occur simultaneously" in another.

MODIFIABLE

. The requirements document should have a coherent and easy-to-use organization, with a table of contents, an index and explicit cross-referencing. Requirement statements should be non-redundant where possible. 

TRACEABLE

The origin of each requirement should be clear, thus facilitating 'backward traceability' to previous decisions made, and 'forward traceability' to all documents 'spawned' from the requirements document. 

USABLE

The requirements document should be designed such that it can be referred to and if necessary modified throughout the life of the product. It should be usable even in the operation and maintenance phases. 

PROTOTYPING REQUIREMENTS

Fact: the clients do not know what they want Two approaches to prototyping: throw-away and

evolutionary A throw away prototype is software developed to

learn more about a problem or explore the feasibility or desirability of possible solutions. It is exploratory, and it is not intended to be used as an actual part of the delivered software. 

EVOLUTIONARY

An evolutionary prototype is developed to learn about a problem and form the basis for some or all of the delivered software.  For example, if customers are not sure what kind of user interface they want for their system, you can build several evolutionary prototypes for them and once one interface is chosen, the prototype can be developed into actual interface and delivered with the rest of the product. 

VALIDATING

determining whether the specification is consistent with the requirements definition 

making sure that the requirements will meet the customers' needs

  techniques:

– reading – manual cross-referencing – interviews – reviews – checklists – manual models to check functions and relationships – scenarios – mathematical proofs

RE Negotiation

Customers and users, who must understand the requirements so that they can be sure the system will meet their needs.  Business managers, who must understand the likely consequences of building and using the system Designers, who use the requirements as a basis for developing an acceptable solution that will be implemented as a software-based system Testers, who develop test data and test suites to ensure that the software system satisfies each requirement.    However, there are a lot of conflicts, so the requirements analyst who performs the requirements elicitation must have the ability to understand each view and capture the requirements in a way that reflects the concerns of each participant. 

Data Gathering Methods

Common methods are:  Interviewing  Questionnaires  Observation  Repertory Grids  Concept Mapping  Joint Application Design  Contextual Design

INTERVIEWING

the most widely used technique in requirements engineering. 

Analysts interview future users of the system individually to find out: 

what the present system does and  what changes are needed. 

FIVE STEPS:

Preparing for the interview  Planning and scheduling the interview  Opening and closing the interview  Conducting the interview  Following up for clarification 

Preparing for the Interview

REVIEW

organization reports  annual reports  long-range planning documents  statements of departmental goals  existing procedure manuals and  systems documentation  maybe even your old math or physics text books 

BE FAMILIAR WITH INDUSTRY’S TERMS!

PLANNING AND SCHEDULING

Prepare a list of topics and questions to be covered to help ensure that important points are not overlooked and that the interview follows a logical progression.  Scheduling interviews should proceed from the top down. 

Heads of departments or sections are usually interviewed before employees who report to them. 

Interviewers should explain the purpose of the interview, the general areas to be covered, and the approximate amount of time required to cover all areas.   

ATTITUDE

During the entire interview, the analyst should adopt a posture of objectivity and avoid personal comments, observations, or conclusions. 

Avoid closed questions as the result of this approach is usually that the interviewees give a brief answer to the question and then wait for the next one, almost as if they were being interrogated by a detective.

ATTITUDE

Active listening helps to maintain the information flow and facilitates adequate feedback from analyst to interviewee. 

The active listening technique has five key tools:  Asking open-ended questions  Using appropriate words and phrases  Giving acceptance cues  Restating the interviewee's responses  Using silence effectively 

HOW TO INTERVIEW

Closed questions: (who, where, when, which)  set limits on the type, level and amount of information

interviewee provides  often provide a choice of alternatives  can require a bipolar or multiple choice response  used for clarifying or probing questions or as feedback  less time consuming for specific information  makes note-taking easier  sometimes can get too little information  may stop interviewee from volunteering information  requires an excellent command of vocabulary and concepts

How to Interview

Open questions: (what, why, how)  “Tell me what happens when a customer calls? are broad and place few constraints on the interviewee  used for determining scope of understanding, response

certainty, models used allow expert to express information knowledge engineer does not know about 

can obtain interviewee`s vocabulary, concepts, frames of reference 

can help with explanations and underlying theory

How NOT to …

Sitting back in a chair with arms folded across the chest (This posture implies a lack of openness to what is being said and may also indicate that the analyst is ill at ease.) 

Looking at objects in the room or staring out the window instead of looking at the interviewee. (Because this behavior suggests that the analyst would rather be somewhere else doing other things, the interviewee will often cut the interview short.) 

Taking excessive notes or visually reviewing notes. (An analyst who records rather than listening may arouse interviewee concerns over what is being written.) 

Sitting too far away or too close. (Sitting too far away often communicates that the analyst is intimidated by the interviewee, while sitting too close may communicate an inappropriate level of intimacy and make the interviewee uncomfortable.)

Restating the interviewee’s responses

When the interviewee is describing a problem. (At such times, the analyst's restatement communicates that the interviewee's problem has been heard and understood.) 

When the analyst wants to check his or her understanding of what has been said. (This technique is often used in response to complex statements or in group situations where several persons have commented on the same issue.) 

When the analyst wants to encourage the interviewee. (Restatement can prompt the interviewee to expand or elaborate on what has been said.)

… How NOT to…

Echoing the interviewee, i.e., repeating exactly what the interviewee has said rather than restating in different words. (Echoing becomes very obvious after the first few times it occurs and can make the interviewee uncomfortable. 

Overusing restatement, which can be distracting to the interviewee. 

Altering or distorting the meaning intended by the interviewee. (A restatement should be as close to the interviewee's meaning as possible.) 

Raising the pitch of the voice at the end of a restatement. (This habit converts a restatement into a question answerable by yes or no instead of an invitation for the interviewee to expand on his or her comments.) 

EXAMPLE

Interviewee Response: We continue to sell products to customers who have not paid their bills. 

Effective Restatement: The system processes orders to customers who are bad credit risks. (Encourages interviewee to expand.) 

Ineffective Restatement: Why don't you check the customer's credit status before processing the order? (Distorts interviewee's meaning.) 

DOCUMENTING THE RESULTS – see website notes