DATA GATHERING (REQUIREMENTS)

صفحه 1:
620۲۶ ۷ ۵0۵ وام 

صفحه 2:
REQUIREMENTS DEFINITION |AND SPECIFICATION REQUIREMENTS ELICITATION, ANALYSIS AND NEGOTIATION Prototyping Documentation snd testing and validation The p rocess of determining requirements 

صفحه 3:
کلب موه ‎First, the developing tea‏ و ‎pustowers to elicit he nequirewwedts, by ashi‏ ‎sive systews, or eve‏ مت ومیل ‎qnesiivw,‏ ‎ppolew.‏ 

صفحه 4:
۵۵ را دح ااي ‎Domain models‏ تت _ ‎ame‏ i و سمل ‎aan‏ ۳ Raking requirements ore or Reusable Suggested types Rew ponte: of rey urements / ‏وود ها ععبه از‎ Requirements template le requirements (Robertson and Robertson 1997) ‘Source of pos: 

صفحه 5:
۵ 10/۲۰/۲۳۹۵ را 

صفحه 6:
4۶0. ۵ © ‏با‎ require weuts dePiciiva domed is 0 powwplete proposed systes to do. 11 ‏وص‎ ot ‏وه موه عا مارب ان‎ pr wots, oer if ie 

صفحه 7:
4٩۶0۰. ۵۵ م معا مهو جما و مه و و 0 1-7 | را و بر ‎write‏ ‏دوعسم وو ‎(esmecors per doesnot cea sree brs paren,‏ او ساوسو موه وه ما موم ‎designers. @ui oPea bots eer oP doracoecis ore aeeded, od te cord‏ و ابص وی ارجا و ‎ts foe‏ مها ‎thet or‏ 0 

صفحه 8:
خاو عمط ملظ امد نو شید و the spstew © wo Pucntiood requireweds (DP Rs) deseribe ‏موه مه اوه‎ (e.y. sevuniy, rebabiliy, portubliy, soPety, perPorwour) ‎baci]‏ زر تا و یا يون ا صمي عمو م اد ‏اس ساوسو 

صفحه 9:
0000102001١ 00 ٩ ۵۶ 00000000002001١ ‎oP the qecerd purpose oP the sysiew‏ نهر ‏مويو خا ‎the bockyrournd wed obievives‏ اه مسب و اجه مه امه ‎develppwedt (2.4. iP the sysiew is i‏ ‎wpprowh)‏ 

صفحه 10:
© Reqirewed 4۱.9.۸۰ 1/۳۹/۳۵ ۵ 1D@CE. Logicd provessiag shal be doar ‏هه‎ ۵۶ TPROCK OO IDOEGE. This shall have as foput WPOODOOER O@TO. This shall have as vulzut WO, GTOVE DONO ud IOPECE 10. This togical procession, whe uppropricte, sho ‏موه بو وه رام‎ oP IDOE. This lrgicd procession, wheo appropriate, shall ideaiPy the ype oP eutiy tostoare ‏عمصط جه‎ ID PGE OM TPROCK. DONE: a request Por pulses is wade by ‏منطو‎ a Porvoo record fata the WOT whick Peeds the palse-secnt procedures. 

صفحه 11:
BOLEWO: IDIMBONE_MRBOK_OO_1DOG6E. 41000۳00۴۳۵۰: 2123000006636 ۰ 6001۳۵۵/۵۰ ٩1۸۵۹۱۵۰ ۵/065/۳۵۰ *)69600۶ ۰ OREOTEG: 1IDOGE. GEVENDOGE_OD ۰ ODEGORIPMOD: "(F.4.9.d) B REQDEGT COR POLGE 16 DOOE OY EOVERIOG © PORMBL RECORD REQOESTN 1OTO MLE WO1Q OW10W PEGCOE MLE POLGE 8 PROCEDOREG." 

صفحه 12:
OWVOROCTERIGMC OP REQO1IREDEOTG © Waxnky 199?) 

صفحه 13:
۱۹۹0 ۰ equine weds one ‏مرها امه و وا مرن ماه‎ where stueweuts moo hove wore tho poe wesc. (Pond requineweuts hrouages help reduce ‏ینارون‎ ۰ 

صفحه 14:
2۵ رها ۸ موی یحو او ‎Dhe‏ © ارب ,جوم منود لا چاه له سل( ‎desiqa‏ جك مسرم ور لاتادوصةعصسخا ۱ ‎utributes or extercal icterPaves ord‏ | موه ‎powPors to the powpoapy‏ 

صفحه 15:
۰ ۲0 ‏هچ واحاه “امور دوو ۲و عاممممجه‎ is "the product skould Kove a ‏لو‎ hucvad ioterPace". (or pxawple oP a veriPiable nequineweul is "Ihe systew wil respowd to a user request wii OO seve oP the user pressing the cuter key, 6006 ‏ان‎ the fico" 

صفحه 16:
COOGIGTEDT Dkree types oP oooP ict whick coo cour oe: ©» ‏حون مها محرو ندل‎ Por the sae vbievt! Por ‏رام‎ ‎PCS" ced "a tors Porc" wight be used to describe the soe Pore. ‎oP pbjevts cooblint) Por exacvple, ica poe port of‏ موی و ‎the requirewees deposed, “cred fybt vil tocicote o Rout",‏ ‎while io canter port, “a bhoe tet will torciccte a Pout".‏ ‎© logicdl or texopordl Pouls: Por excple, "@ Pols " it vo ] aed @ ooour sicvutecezusly" i caiker. 

صفحه 17:
0 Vee requirewedts domed should hove o vokereut ‏مه‎ wits a table Require wed stoteweuts should be averrederdcrat 

صفحه 18:
© ‏مرن با‎ oP euck require wed should be clear, thus Paviltattacy ‏نطو‎ traseubiliy! to previous devisioas wade, werd 'Porwvard teaceubilip’ to off domueds 'spaweed' Brow the requirewects domed. 

صفحه 19:
© ‏مج موه نوس با‎ should be designed ۱ iP oepessury woodiPied throughout the Pe oP the product. It should be usable even io the pperaiog ced woicteoca6e phuses. 

صفحه 20:
۳86 REQOIREDEDTG © (oot the chests do ot Keo whet they vost © Dw upprouckes ty proipippicg throwaway ood ‏مارد‎ © 0 tow wy propre is svPiwore developed to bear wore ubout o problew or explore the Peosibtiiy or desircbiliy DF possible svluives. It is exploratory, ved it is ont ‏دا للجم‎ be used us oc -octud port of the delivered sR. 

صفحه 21:
۵۲ ‎prope is developed to leur obout a‏ ارو ول و ‎problew ocd Porc the basis Por sowe or oll oP the delivered‏ ‎Por exanple, P oostowers ure ot sure what‏ .جمس امد ‎iad oP user ioterPace they vod Por their systew, pou oot‏ ‎build severd euchiiosary protippes Por thew ont cue oor‏ مسجت و ‎interPuce is chosen, the proiippe coo be developed‏ ‎ioterPuce ood delivered wits the nest oP the product.‏ 

صفحه 22:
0۵۵ ماما وحن موی ها تمه لا ان مد ‎requineweuts wil weet he custowers' weeds‏ سا ما و بت و ماما لجی هی امن با ‎wend wink‏ 5500 مكاسم ‎wwakewatrdl‏ 

صفحه 23:
ام بو با لممطلیی سوه نت وی لو چبومیین 0‏ ۰ ‎wert their ceeds.‏ اس ‎hey cou be sure he syste‏ ‎Orskess worners, why ove unkrstosnl the they oxmexueucey oP‏ مرو با وی له بط ‎boss Por develope ot‏ 0 جد صصص شوج ‎Orokners, who se the‏ موه ماو و بو اما و ‎vod‏ مكل ‎srk ae‏ او ‎soP aware‏ با نم مج ‎test suites io‏ لجه طل ابا مرو ون ویو بو لو ماود مور ارت دراه مرو و خر خه بو و و و جوا اما و رو وا مه ما موم وا روط جما تا و ‎view ond cophine the requineeds no way‏ کی ‎pb aks parte,‏ موم 

صفحه 24:
Cowon wethods ue eter vie vier ‏نموه‎ ‎Observativa ‎Repertory Grids Ovuwept Duppicry loict @pphicaiva Desige Coctextuad Desicqet 

صفحه 25:
۲ © ‏با‎ wost widely Used techoique ia requineweuts (Qolvets interview Putune users oP the systeuw ‏ان( وا ارهز‎ wut: ۰ What the preseu systesw does ocd © What chonyes oe ceeded. 

صفحه 26:
۳۱6۶ GTEPG: 

صفحه 27:
و من ولمم سح نان جوا ی او اه موه ‎wns or‏ ی[ ‏ممم حمل ‎py‏ ‎physics tet books‏ و کم لاه ‎your‏ مويص «تاتوديه ‎26 ۳۵0/۱۵4 ۵۳۲۲ 1۵۵0۵/۳۷۵ 0۵۱ 

صفحه 28:
00 06000010006رام) ‎GOVEDOLIOG‏ reper abet oF opis ond questions ty be covered to help posure trot Keportast points ore ool overlooked cad tral ire interview Plows ot bovierd pression. Ochedvhay iierviews should proceed Brow the top dow. © Whew of deporknedis or serio ore any fier ‏ها‎ ‏وروی‎ who repo io thew. © ote viewers should exphic the purpose ‏اج برش با چاه‎ anew ty be covered, ond the opproxkrae amour oF ‏او و‎ cover dl areas. 

صفحه 29:
۱ © )]( ‏اس ی رتصواه ی با حجنن‎ ۳ poulusivas. © Quod dosed questives us the result oP this upprouk is sully thot the ioterviewers yive a brieP coswer to the questioo ood theo Wait Por the cext poe, ukvost os (Phe were beta ‏جب ماعل ه برط تیه‎ 

صفحه 30:
۱ Qotve tstectag ‏له سا موجه لا اوه سا عماج‎ ‏و۳‎ adequate Peedback Prow oslyst to ‏.هروه‎ ‎Phe ontive tsteciag techoique kos Pive key tools: ]0 ppew-euded questivas Osten uppropriate words und phruses ‎pues‏ جححهاوروصعه كانه ج9ومموم ] ‎sileure ePPevively‏ رو( 

صفحه 31:
WOO TO ۳0 Obsed questo: (why, where, when, whick) ‏موه موه و و له اما ,را من جرا بو‎ provides هو خر موی و ‎prints‏ مر و اه وش و وا موی مر ‎or az Peedbacks‏ ون ره وراه و ای ‏ممعم مكالم تامسر وخا تم جيم تدم صل ‏مه او را و او ات و مهو 

صفحه 32:
Oped questions: (what, why, how) “Dell oe what happees wheo a pion cals? are broad oad place Pew powsindeis 70 he Ker ieee ای راهن مره لوط و سوه مرول بر ‎cena!‏ ‎kam deck rerieey: core? ort‏ ماه مور ما او وله لو له سا صم وه بو روطچ و موه ماه مور ‎oud vader heory‏ و دنت تا میت 

صفحه 33:
و ام جوم ۱ باه عولط موه نت شاه ولمم ‎Gitte‏ ‏تاک ‎pur.‏ Lookiec) of objents tothe roo or store pul the wiedow instead oP bobiery ot the fiteruiewer. ((Becouse this behavior sucuests thot the omdyet waukd rather be Weg ee renames oe eaten neces short. “Doki, excessive uies or visvaly reviewiay wies. (Ba ordyst who records rearrested oy writes. (Gitte to Por away or too close. (Gitte tor Par ‏ام موی اه پویه‎ the coals ts foteridated by the taterviewsr, while sitio too close way pout wo ‏موه‎ level oF ‏وهای نموه لیلج بو‎ 

صفحه 34:
جما ,تن ‎desorbtay 3 problew. (1 suck‏ & نها ‎Okeu he‏ ها مان مس ما ها موه متسر 0 (hea the ooayet wots to ‏مان اه یه ام‎ hear ‏اه وا رو نز لو ماه سا سوت )مت ما‎ ؤز ز ز ز [ ز[ز[ز ز [ [ [ |[ [ [ 0 0 وم اه و ‎po the sere tur.)‏ ] he osdyet wens to parang the fier iewer. (Restart ot peowpl he terviewsr io expand or ehborae oa what kas ber sic.) 

صفحه 35:
Cohoray he hier iewer, Le. repeat pracy whol the Kier viewer beer ‏بجاو مس لو‎ it dPPerect words. (Bchorn bere very pbviows Pier the Pret Pew ives fl ooruns ued co wah the fier ewe racer Babe Ouenwty resktowed, Wwhick coo be dstrantiog to the toerviewer. lente or dstortay the weccicy toteoded by the toterviewsr. (BD restaieweu should be os close i he Kerviewee's wean) os possble.) QRustag the pick oP the voice of he ead oP a restatewedt. (This habit ‏يحي مایت فا یعاس سرت‎ abe by peo vr ae Relea ‏عل‎ ‎uu eviction Por he tier viewer 7 expoad ou kis or ker cowwedts.) 

صفحه 36:
0۳ ‎to sel products to‏ مج ‎aterviewer Respouse. De‏ و ‎have ont port their bits.‏ ] ‎٠ CP fenive Restaewed. Mke syste processes orders 17 interviewer i expr.) ‎° TeePerive Restaewed. ky doo't you check the pvstower's credit status bePore provessiacy the order? (Oistorts interviewer's weucicy. ) ‎© DOCODEOMOG MLE REGOLTG = see website wies 

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