Requirements Analysis - Principles of Software Development - Lecture Notes, Study notes of Software Engineering

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

2012/2013

Uploaded on 04/23/2013

ashakiran
ashakiran ๐Ÿ‡ฎ๐Ÿ‡ณ

4.5

(27)

261 documents

1 / 33

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Recall the waterfall model
Requirements / Design / Implementation / Testing /
Maintenance
assuming anything about the customer.
a.
describing how to do it.
b.
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
10:35 AM
Requirements Page 1
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21

Partial preview of the text

Download Requirements Analysis - Principles of Software Development - Lecture Notes and more Study notes Software Engineering in PDF only on Docsity!

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