

























Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Main points of this lecture are: Requirements Analysis, Waterfall Model, Elicitation Methods, Requirements Versus Design, State Diagrams, Control Flow Charts, Task Management, Entity/Relationship Analysis, State Diagrams, Space Diagrams
Typology: Study notes
1 / 33
This page cannot be seen from the preview
Don't miss anything!


























Recall the waterfall model Requirements / Design / Implementation / Testing / Maintenance a. assuming anything about the customer. b. describing how to do it. Requirements analysis refers to the art of precisely specifying what a project should do, without Between developer and client about what the product should do. a. Between the requirements team and the design team, about the client's needs. b. Thus requirements analysis is mostly about effective communication: Requirements analysis Wednesday, September 16, 2009 10:35 AM Docsity.com
a. Don't assume anything. b. When in doubt, ask. Avoid making design decisions before the design phase. c. d. Employ accepted elicitation methods. e. Seek consensus. Some simple rules: Some simple rules Wednesday, September 16, 2009 10:42 AM Docsity.com
Requirements describe what to do. Design describes how to do it. Most common software engineering mistake: mix up design with requirements. Why is this a bad thing? Requirements versus design Requirements versus design Monday, September 10, 2012 3:45 PM Docsity.com
Dictionaries : listing all of the entities involved and their precise definitions. โ Use cases : creating a "script" of one or more specific kinds of use. โ Entity/relationship analysis : documents how entities interact. โ State diagrams : document how entity states can change, and why. โ Time/space diagrams : document how entities interact over time. โ Control flow charts: describe the actions of a single entity. โ Data flow charts: describe how data is exchanged between entities. Several basic requirements analysis and elicitation techniques: Requirements analysis basics Wednesday, September 16, 2009 10:51 AM Docsity.com
A user browses to the website. Website says "login". User enters username and password. Website shows tasks to be done today. Buttons on website allow viewing of all tasks and entering new tasks. User presses the button to see all tasks. User enters a new task. Task appears in list of all tasks, in alphabetical order. User selects the category "Inbox". Website shows all tasks in that category. New task appears in the category "inbox". User clicks on the task. Task is checked in the list. User types "c". Task is marked as completed. Use case Wednesday, September 16, 2009 12:17 PM Docsity.com
Entities: nouns in the system Interactions: verbs Arrows: transitive verbs Entity/relationship analysis Wednesday, September 16, 2009 12:17 PM Docsity.com
Time/space diagrams Wednesday, September 16, 2009 12:18 PM Docsity.com
Control flow charts: Process Sequence Decision Initiation/termination Control flow charts Monday, September 10, 2012 3:50 PM Docsity.com
Data D flows from A to B Data flow Monday, September 10, 2012 3:54 PM Docsity.com
Data flow example Monday, September 10, 2012 3:56 PM Docsity.com
โ high level of abstraction โ in language understandable to the client โ but precise enough to empower design. The requirements document is a bridge between the client and the designers. Raising the level of abstraction Wednesday, September 16, 2009 12:18 PM Docsity.com
domain analysis : understanding similar problems
modeling : keeping requirements high- level and specific to the problem domain.
stepwise refinement : from general to specific
Some more general survival mechanisms: Survival mechanisms Wednesday, September 16, 2009 11:34 AM Docsity.com
โ raises the level of abstraction โ generates more understandable depictions of state โ documents one aspect at a time Modeling Modeling Wednesday, September 16, 2009 11:35 AM Docsity.com
Scenario-based models: describe a product's use in context. โ โ Behavioral models: describe time-varying behavior. โ^ Data^ models: describe input and output structure. Class models: describe entities and interactions without considering time (document interface instead). โ โ Flow models: describe movement ("flow") of data. Kinds of models: Kinds of models Wednesday, September 16, 2009 11:29 AM Docsity.com