DATA GATHERING (REQUIREMENTS)
اسلاید 1: DATA GATHERINGREQUIREMENTS
اسلاید 2:
اسلاید 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 TECHNIQUESinterviewing group sessions observations scenarios and use cases prototyping
اسلاید 6: REQ. DEFINITIONThe 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. SPECIFICATIONThe 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-Functionalfunctional 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 DOCUMENToutline 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)
اسلاید 10: EXAMPLERequirement 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: FORMALALPHA: 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.
اسلاید 12: CHARACTERISTIC OF REQUIREMENTSunambiguous complete verifiable consistent modifiable traceable usable (Macaulay 1997)
اسلاید 13: UNAMBIGUOUSRequirements are often written in a natural language where statements can have more than one meaning. Formal requirements languages help reduce ambiguity.
اسلاید 14: COMPLETEThe 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: VERIFIABLEAn 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: CONSISTENTThree 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: TRACEABLEThe 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: USABLEThe 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 REQUIREMENTSFact: 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: EVOLUTIONARYAn 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: VALIDATINGdetermining 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 NegotiationCustomers 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 MethodsCommon methods are: Interviewing Questionnaires Observation Repertory Grids Concept Mapping Joint Application Design Contextual Design
اسلاید 25: INTERVIEWINGthe 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 InterviewREVIEWorganization 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!
اسلاید 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: ATTITUDEDuring 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: ATTITUDEActive 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 interviewees responses Using silence effectively
اسلاید 31: HOW TO INTERVIEWClosed 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 InterviewOpen 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
اسلاید 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 interviewee’s responsesWhen the interviewee is describing a problem. (At such times, the analysts restatement communicates that the interviewees 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 interviewees 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: EXAMPLEInterviewee 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 dont you check the customers credit status before processing the order? (Distorts interviewees meaning.) DOCUMENTING THE RESULTS – see website note
نقد و بررسی ها
هیچ نظری برای این پاورپوینت نوشته نشده است.