Approaching a Problem.ppt

1、08a-Requirements1,1,Approaching a Problem,Where do we start? How do we proceed?,2,08a-Requirements1,Where Do We Start?,Start with the requirements Capture your goals and possible constraints Environmental assumptions Use-case analysis to better understand your requirements Find actors and a first ro

2、und of use-cases Start conceptual modeling Conceptual class diagram Interaction diagrams to clarify use-cases Activity diagrams to understand major processing,3,08a-Requirements1,How Do We Continue?,Refine use-cases Possibly some “real” use-cases Using interface mockups Refine (or restructure) your

3、class diagram Based on your hardware architecture For instance, client server Refine and expand your dynamic model Until you are comfortable that you understand the required behavior Identify most operations and attributes,4,08a-Requirements1,How Do We Wrap Up?,Refine the class diagram based on plat

4、form and language properties Navigability, public, private, etc Class libraries Identify most operations Not the trivial get, set, etc. Write a contract for each operation Define a collection of invariants for each class Implement,5,08a-Requirements1,Putting It Together,Principles Rigor and Formalit

5、y Separation of Concerns Modularity Abstraction Anticipation of Change Generality Incrementality Notion of Process,6,08a-Requirements1,Waterfall Approach,Gather Requirements,Generate Design,Requirements Documents,DesignDocuments,WriteCode,Implementation,Test,Domain language,Models, technical languag

6、e,7,08a-Requirements1,Frequent Industrial Approach,Gather Requirements,Generate Design,Requirements Documents,DesignDocuments,WriteCode,Implementation,Test,Prototypes,8,08a-Requirements1,Sensible Approach,Gather Requirements,Generate Design,Requirements Documents,DesignDocuments,WriteCode,Implementa

7、tion,Test,Prototypes,iterate,9,08a-Requirements1,Process Overview,Inception Elaboration Construction Many iterations Transition,08a-Requirements1,10,Requirements Analysis,Defining the WHAT,11,08a-Requirements1,Requirements Elicitation Process,System,Client Domain,Client,Problem,Us,SRS,12,08a-Require

8、ments1,Requirements,Specify functionality model objects and resources model behavior Specify data interfaces type, quantity, frequency, reliability providers, receivers operational profile (expected scenarios) stress profile (worst case scenarios),13,08a-Requirements1,Requirements,Specify interfaces

9、 Control interfaces (APIs) User interfaces - functionality and style Hardware interfaces Specify error handling Identify potential modifications,14,08a-Requirements1,Requirements,Identify necessary constraints performance, security, reliability Identify areas of risk alternatives to be explored Spec

10、ify validation plans Specify documentation to be provided,15,08a-Requirements1,Analysis Principles,Document reason for specific requirements Prioritize requirements High, medium, low Ignore implementation details Need to know feasible solutions can be developed If feasibility is a concern, then prop

11、ose alternatives to be explored Be prepared to change,16,08a-Requirements1,Perspective and Early Binding of Constraints,A,A,B,C,B,C,Connect like letters withoutcrossing lines or leaving box.,17,08a-Requirements1,Early Focus on Constraints,A-A line seems to be only solution But, is it really? Need to

12、 examine domain and constraints more? What transforms or shifts would yield easier problem?,Early choice, eliminates C,B,18,08a-Requirements1,Focus Change,A,A,B,C,B,C,These choices still leave a path between As,A,A,B,C,B,C,Transforms to:,19,08a-Requirements1,Reviewing a requirements document,Is it a

13、mbiguous? Carefully define terms and use these terms Is it consistent? Is it complete? Vague requirements Omitted requirements Is it verifiable? Is it realistic? Does it plan for change?,Does it not overly constrain the problem? Have alternatives been considered and explored? Is it clearly presented

14、? Precise, concise, clear diagram complex objects and behaviors Is it what the customer wants?,20,08a-Requirements1,Why is requirements analysis difficult?,Communication: misunderstandings between the customer and the analyst Analyst doesnt understand the domain Customer doesnt understand alternativ

15、es and trade-offs Problem complexity Inconsistencies in problem statement Omissions/incompleteness in problem statement Inappropriate detail in problem statement,21,08a-Requirements1,Escalator System Requirements,Shoes Must Be Worn,Dogs Must Be Carried,Two Signs on Escalator:,You must have on shoes,

16、 and you must be carrying a dog.,If you have a dog, you have to carry it, so you have to wear all the shoes you are carrying.,If you dont have a dog, you dont need to carry it, so you dont have to wear shoes unless you are carrying some.,Consistent Conclusions:,22,08a-Requirements1,Why is requiremen

17、ts analysis difficult?,Need to accommodate change Hard to predict change Hard to plan for change Hard to foresee the impact of change,23,08a-Requirements1,First Law of Software Engineering,“No matter where you are in the system lifecycle, the system will change, and the desire to change it will pers

18、ist throughout the lifecycle.”,24,08a-Requirements1,Reasons for changing requirements,Poor communication Inaccurate requirements analysis Failure to consider alternatives New users New customer goals,New customer environment New technology Competition Software is seen as malleable,Changes made after

19、 the requirements are approved increase cost and schedule,25,08a-Requirements1,Requirements Products,Specification document Agreement between customer and developer Validation criteria for software Problem statement in domain language external behavior constraints on system Preliminary users manual

20、Prototype (do not deliver the prototype!) If user interaction is important If resources are available Review by customer and developer Iteration is almost always required,26,08a-Requirements1,Overview: Steps to Follow,Map out environment as-is Map out environment as required Decide on systems bounda

21、ries / goals List actions with types Define terms Construct model Challenge model Modify as required,27,08a-Requirements1,Analysis: Steps to follow,Obtain a problem statement Develop use cases (depict scenarios of use) Build an object model and data dictionary Develop a dynamic model state and seque

22、nce diagrams Verify, iterate, and refine the models Produce analysis document,28,08a-Requirements1,Use Cases,High-level overview of system use Identify scenarios of usage Identify actors of the system: External entities (e.g., users, systems, etc.) Identify system activities Draw connections between

23、 actors and activities Identify dependencies between activities (i.e., extends, uses),29,08a-Requirements1,Analysis: Object Model,Organization of system into classes connected by associations Shows the static structure Organizes and decomposes system into more manageable subsystems Describes real wo

24、rld classes and relationships,30,08a-Requirements1,Analysis: Object Model,Object model precedes the dynamic model because static structure is usually better defined less dependent on details more stable as the system evolves,31,08a-Requirements1,Analysis: Object Model,Information comes from The prob

25、lem statement and use cases Expert knowledge of the application domain Interviews with customer Consultation with experts Outside research performed by analyst General knowledge of the real world,32,08a-Requirements1,Client View of Domain,Clients cant be expected to have rigorous or formal view of d

26、omain Hence, cant be expected to be completely aware of domain-problem relationship Some knowledge is explicit Easier to get at Some knowledge is implicit (“everybody knows”) Many constraints are implicit Hard to get at,33,08a-Requirements1,Object Model: Steps to follow,Identify classes and associat

27、ions nouns and verbs in a problem description Create data dictionary entry for each Add attributes Combine and organize classes using inheritance,34,08a-Requirements1,Analysis: Dynamic model,Shows the time dependent behavior of the system and the objects in it Expressed in terms of states of objects

28、 and activities in statesevents and actions State diagram summarizes permissible event sequences for objects with important dynamic behavior,35,08a-Requirements1,Dynamic Model: Steps to follow,Use cases provide scenarios of typical interaction sequences Identify events between objects (Sequence Diag

29、ram) Prepare an event trace for each scenario Build state diagrams Match events between objects to verify consistency,Do this,36,08a-Requirements1,Analysis: Iteration,Analysis model will require multiple passes to complete Look for inconsistencies and revise Look for omissions/vagueness and revise V

30、alidate the final model with the customer Pose scenarios from various perspectives Look for consistency in responses,37,08a-Requirements1,Object Model: Four main system objects or classes,Controller object might be made up of several controllers is the brains of the system. Takes input from the sens

31、ors and gives instructions to the actuators. Sensor object environmental objects that gives information to controller. Can be passive (thermometer) or active (button).,38,08a-Requirements1,Meeting Purposes,Disseminate information (including stating a problem)Gathering opinions Confirming consensus S

32、ocial requirements team building approval,39,08a-Requirements1,Meeting Requirements,Agenda Leader Action list With assignments so we know who is doing what. Timelines so we know when its to get done. Summary Something happened or there would not have been a meeting. Record it briefly.,40,08a-Require

33、ments1,Project Issue List,Every issue goes on the list Date and brief description Make assignment to get it resolved Put resolution on list. “Close” issue. 1st version usually generated on 1st read of problem statement. And then, back to the customer.,41,08a-Requirements1,Interviewing,Have a list of

34、 things you want to know. Listen. Listen. Ask open-ended questions. Dont express (show, say) opinions on answers. Just record, and think. Listen. Ask questions more than one way.,42,08a-Requirements1,Close-ended questions,Q: When a vehicle cuts in front of the car, you have to slow down quickly and

35、not hit it, right?,A: Yes.,You learned absolutely nothing.,43,08a-Requirements1,Open-ended questions,Q: Tell me what happens when a car cuts in front of you.,A: Well, if the lead car is too close, the driver has to intervene or else a crash results. I guess we need a warning light in this case. If t

36、he car is moving faster, you dont have to do anything. Hes pulling away. I guess the only time brakes are used is when the closing speed is too high for the distance and yet within the capabilities of the system to slow down. But I guess if a collision is imminent, we should max out the braking.,Now

37、, we learned something.,Ah ha!, new requirement!,And a clarification,44,08a-Requirements1,Responses,Q: Tell me what should happen if a car cuts in front of our car too closeto avoid a collision?,A: I guess since there is nothing thesystem can do. Turn off the controllerand hope the driver brakes in

38、time.,Q: We have quite a bit of braking powerin the system. What would happenif we used it here?,A: Well, I guess it could avoid a collisionand at least get the car slowed down butthe attorneys tell me we dont want thesystem active when a collision occurs.,Q: What? Are you nuts? We should at leasttry to stop. Shouldnt we?,A: Perhaps.,Not good,Much better,You are done at at this point,and still unresolved.,Ah ha! Non-technical constraint,