1 / 36

DATA GATHERING

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

baylee
Download Presentation

DATA GATHERING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DATA GATHERING REQUIREMENTS

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

  3. ELICITATION

  4. ELICITATION TECHNIQUES • interviewing • group sessions • observations • scenarios and use cases • prototyping

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

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

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

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

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

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

  11. CHARACTERISTIC OF REQUIREMENTS • unambiguous  • complete • verifiable • consistent • modifiable • traceable • usable • (Macaulay 1997)

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

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

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

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

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

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

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

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

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

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

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

  23. Data Gathering Methods • Common methods are:  • Interviewing  • Questionnaires  • Observation  • Repertory Grids  • Concept Mapping  • Joint Application Design  • Contextual Design

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

  25. FIVE STEPS: • Preparing for the interview  • Planning and scheduling the interview  • Opening and closing the interview  • Conducting the interview  • Following up for clarification 

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

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

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

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

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

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

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

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

  34. … 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.) 

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

More Related