DATA GATHERING

1
DATA GATHERING

• REQUIREMENTS

2
(No Transcript)
3

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

4
ELICITATION
5
ELICITATION TECHNIQUES

• interviewing
• group sessions
• observations
• scenarios and use cases
• prototyping

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

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

8
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)
•  

9
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 (NFRs)

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

11
FORMAL

• ALPHA INITIATE_TRACK_ON_IMAGE.  INPUTS
  HANDOVER_DATA.  OUTPUTS HOIQ. STATE_DATA,
  IMAGE_ID.  CREATES IMAGE.  SETSIMAGE_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." 
•  

12
CHARACTERISTIC OF REQUIREMENTS

• unambiguous 
• complete
• verifiable
• consistent
• modifiable
• traceable
• usable
• (Macaulay 1997)

13
UNAMBIGUOUS

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

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

15
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"

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

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

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

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

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

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

22
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

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

24
Data Gathering Methods

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

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

26
FIVE STEPS

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

27
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 INDUSTRYS TERMS!

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

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

30
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 

31
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

32
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 interviewees vocabulary, concepts,
  frames of reference 
• can help with explanations and underlying theory

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

34
Restating the interviewees 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.)

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

36
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