Study Guides (258,872)
CA (125,029)
Ryerson (8,700)
ITM (476)
ITM 430 (2)
Final

Final Prep.docx

18 Pages
236 Views

Department
Information Technology Management
Course Code
ITM 430
Professor
Junlian Xiang

This preview shows pages 1-3. Sign up to view the full 18 pages of the document.
Requirements Analysis - The purpose of requirements analysis is to
understand some of the goals of the computer system that we will design.
Use case model
Supplementary specification
Glossary
Vision
Business rules
Use cases - provide a way of describing the functional requirements through
stories of using the system.
a use case is a text story of some actor using a system to meet goals.
Use cases are not diagrams. They are TEXT.
Use cases are NOT object-oriented artifacts! They feed into other OO models.
Actors - Anything with behavior that triggers use case execution.
Three kinds of actors:
Primary Actor accomplishes goals via use case
Example: the cashier
Secondary Actor provides a service to use case (often a computer system,
but could be an organization)
Example: the automated payment authorization service
Offstage actor is interested in use case results
Example: government tax agency
Scenarios - a specific sequence of actions and interactions between actors and the
system.
It represents a one possible path through the use case.
Three possible use case formats
Write in an ‘essential’ UI-free style.
“Keep the interface out; focus on intent.”
Write terse use cases, i.e., make your style “brief and to the point;
effectively concise”.
Delete “noise” words, even if it is small word:
Say “System authenticates ...”, rather than “The system
authenticates ...”
Brief format: one paragraph summary usually of the main success scenario
Casual format: multiple paragraphs that cover various scenarios.
Fully dressed: all steps and variations are written in detail. In addition, there
are supporting sections such as preconditions and postconditions.
Use case Name in ‘Verb Noun’ format
Close Account, Process a Sale
Scope
The system under design
Stakeholders and interests
Who cares about this use case and what they want
Preconditions
What must be true on start and worth telling the reader
Postconditions (or Success Guarantee)
What must be true upon completion of the use case, and worth telling
the reader.
Base Scenario (or Main Success Scenario)
: D ic e G am e
play ()
die1 : D ie
f v 1 : = get F ac eV alue()
die2 : D ie
roll()
roll()
f v 2 : = g et F ac e V alue()
Steps describing the sequence of actions that must occur assuming no
alternative flows or error conditions --- it is the ‘happy day scenario’.
Extensions:
Alternate scenarios
Special Requirements
Non-functional requirements
Technology and Data Variations List
Varying I/O methods and data formats
Frequency of Occurrence
This will influence investigation, testing, and timing of implementation
Miscellaneous
Open issues
Domain model - Creating a domain model is a basic object-oriented step, and is
part of the analysis.
Goal: to identify the major concepts in a domain and express that visually.
UML sequence diagram - shows interactions among software objects in terms of
messages and collaborations in order to fulfill the system requirements .
It provides us with a detailed way to think about how the objects are going to
interact.
Class diagram is a more static diagram, in contrast to sequence diagrams which
emphasizes the dynamics of the design.
P l a y e r
n a m e
D i c e G a m e
D i e
f a c e V a l u e
R o l l s
P l a y s
I n c l u d e s
2
2
1
1
1
1
Models are cohesive set of artefacts meant to describe in an abstracted way some
aspects of the problem at hand, of the requirements, or the system design.
The artefacts could be text, diagrams, or more mathematical.
To record our thoughts when we think about a problem.
To deal with the complexity of systems at hand. Instead of getting into the
details of coding, we want to focus on the big picture or major design
decisions.
Models represent a communication tool for people involved in the software
project.
UML - It is a standard diagramming notation for describing object-oriented software
systems.
It is just a notation, not a process and not a method --- think about civil
engineering or electrical engineering ...
So, one can very well say that it is not important --- it is just a standard for
drawing diagrams
Sequential Waterfall Lifecycle - Requirements, then design, then implementation,
then at the end test ...
The most risky and failure prone approach to develop software, while in
1970s many thought-leaders, books, profs, project managers promoted this
approach as the way to reduce risk and get more successful projects.
Iterative Lifecycle – Iteration lasts between 2 weeks to 6 weeks, but not 4 months or
4 years
Reduces risk and leads to successful projects
Iterations are not allowed to exceed the time that was allotted to them. Once
we chose a period of time, that becomes fixed (remove work or sharpen your
judgement).
Mitigate High Risks Early on:
oSelect requirements in early iterations in such a way that big risks are
discovered early on during the project.
oAs time progresses, risk is reduced, while the full product emerges
[diagram can be drawn with iterations on x-axis]
2
D i e
f a c e V a l u e : i n t
g e t F a c e V a l u e( ) : i n t
r o l l( )
D i c e G a m e
d i e1 : D i e
d i e2 : D i e
p l a y( )
1

Loved by over 2.2 million students

Over 90% improved by at least one letter grade.

Leah — University of Toronto

OneClass has been such a huge help in my studies at UofT especially since I am a transfer student. OneClass is the study buddy I never had before and definitely gives me the extra push to get from a B to an A!

Leah — University of Toronto
Saarim — University of Michigan

Balancing social life With academics can be difficult, that is why I'm so glad that OneClass is out there where I can find the top notes for all of my classes. Now I can be the all-star student I want to be.

Saarim — University of Michigan
Jenna — University of Wisconsin

As a college student living on a college budget, I love how easy it is to earn gift cards just by submitting my notes.

Jenna — University of Wisconsin
Anne — University of California

OneClass has allowed me to catch up with my most difficult course! #lifesaver

Anne — University of California
Description
Requirements Analysis - The purpose of requirements analysis is to understand some of the goals of the computer system that we will design. • Use case model • Supplementary specification • Glossary • Vision • Business rules Use cases - provide a way of describing the functional requirements through stories of using the system. • a use case is a text story of some actor using a system to meet goals. • Use cases are not diagrams. They are TEXT. • Use cases are NOT object-oriented artifacts! They feed into other OO models. Actors - Anything with behavior that triggers use case execution. • Three kinds of actors: – Primary Actor accomplishes goals via use case • Example: the cashier – Secondary Actor provides a service to use case (often a computer system, but could be an organization) • Example: the automated payment authorization service – Offstage actor is interested in use case results • Example: government tax agency Scenarios - a specific sequence of actions and interactions between actors and the system. • It represents a one possible path through the use case. Three possible use case formats • Write in an ‘essential’ UI-free style. – “Keep the interface out; focus on intent.” • Write terse use cases, i.e., make your style “brief and to the point; effectively concise”. – Delete “noise” words, even if it is small word: • Say “System authenticates ...”, rather than “The system authenticates ...” • Brief format: one paragraph summary usually of the main success scenario • Casual format: multiple paragraphs that cover various scenarios. • Fully dressed: all steps and variations are written in detail. In addition, there are supporting sections such as preconditions and postconditions. • Use case Name in ‘Verb Noun’ format • Close Account, Process a Sale • Scope • The system under design • Stakeholders and interests • Who cares about this use case and what they want • Preconditions • What must be true on start and worth telling the reader • Postconditions (or Success Guarantee) • What must be true upon completion of the use case, and worth telling the reader. • Base Scenario (or Main Success Scenario) • Steps describing the sequence of actions that must occur assuming no alternative flows or error conditions --- it is the ‘happy day scenario’. • Extensions: • Alternate scenarios • Special Requirements • Non-functional requirements • Technology and Data Variations List • Varying I/O methods and data formats • Frequency of Occurrence • This will influence investigation, testing, and timing of implementation • Miscellaneous • Open issues Domain model - Creating a domain model is a basic object-oriented step, and is part of the analysis. • Goal: to identify the major concepts in a domain and express that visually. P l aD y i ee r n aR 2f m ace les V a lu e 1 2 1 la y s D 1 I n ec l u ad me se UML sequence diagram - shows interactions among software objects in terms of messages and collaborations in order to fulfill the system requirements . • It provides us with a detailed way to think about how the objects are going to interact. : Dic eG am e die1 : D ie die2 : D ie play () roll() f v 1 : = get F ac eV alue() roll() f v 2 : = get F ac eV alue() Class diagram is a more static diagram, in contrast to sequence diagrams which emphasizes the dynamics of the design. D D i i c e e G d1:D 2f:i n a i ei t c e e d2:D i ei e p( r(i )n o ) l e a t l : l y F Models are cohesive set of artefacts meant to describe in an abstracted way some aspects of the problem at hand, of the requirements, or the system design. • The artefacts could be text, diagrams, or more mathematical. • To record our thoughts when we think about a problem. • To deal with the complexity of systems at hand. Instead of getting into the details of coding, we want to focus on the big picture or major design decisions. • Models represent a communication tool for people involved in the software project. UML - It is a standard diagramming notation for describing object-oriented software systems. • It is just a notation, not a process and not a method --- think about civil engineering or electrical engineering ... • So, one can very well say that it is not important --- it is just a standard for drawing diagrams Sequential Waterfall Lifecycle - Requirements, then design, then implementation, then at the end test ... • The most risky and failure prone approach to develop software, while in 1970s many thought-leaders, books, profs, project managers promoted this approach as the way to reduce risk and get more successful projects. Iterative Lifecycle – Iteration lasts between 2 weeks to 6 weeks, but not 4 months or 4 years • Reduces risk and leads to successful projects • Iterations are not allowed to exceed the time that was allotted to them. Once we chose a period of time, that becomes fixed (remove work or sharpen your judgement). • Mitigate High Risks Early on: o Select requirements in early iterations in such a way that big risks are discovered early on during the project. o As time progresses, risk is reduced, while the full product emerges [diagram can be drawn with iterations on x-axis] • Continuous verification of quality – test early and test often o Load testing (system ability to handle the load) o Usability testing of the UI (getting feedbacks from stakeholders about UI using partial demos) • Embrace change o Rather than trying to fight change, accept it as a positive driver in the software development process. o Look forward to feedbacks from stakeholders. When users say in their feedback it is not exactly what we wanted: don’t groan – say it is great, now we have the right feedback ... • Understand the Phases o INCEPTION: 1 to 5 days – kind of feasibility study  The intent is to establish some initial common vision for the objectives of the project, determine if it is feasible and decide if it is worth some serious investigation in elaboration. o ELABORATION: focus on building the core architecture of the system, and driving down the risks, and identifying 70% or more of the requirements o CONTRUCTION: where we do the rest – the less risky and simple parts of the system. o TRANSITION: release of candidates for feedbacks and evaluation. – Inception is not requirements – Elaboration is not design – Construction is not implementation Rather: - Inception is feasibility - Elaboration is implementing the core architecture - Construction is doing the rest Artifacts in inception • Vision and business case - Describes high-level goals and constraints. • Use Case model - Describes functional requirements and related non- functional requirements. • Supplementary specification - Describes other requirements • Glossary - Key domain terminology • Risk list and Risk Management Plan - Describes business, technical, resource and schedule risks and ideas for their mitigation or response. • Prototypes and proof-of-concepts • Iteration plan - Describes what to do in the first elaboration iteration • Phase Plan & Software development Plan - Guess for elaboration phase duration. Tools, people, education and other resources. • Development Case - Description of the customized UP steps and artefacts for this project. • Artifacts will be partially completed in this phase and will be refined in later iterations. Black-box use cases • Black-box use cases are the ones that do not describe the internal workings of the system, its components, or design. • The system is described as having responsibilities (a common unifying paradigm --- more on this later in course, when we see that objects have responsibilities and collaborate with other objects also with responsibilities). • Writing black-box use cases forces us to think about “what” [purpose of system analysis] the system must do, without deciding “how” [“purpose of system design”] it will do it. How to find use cases: 1. Choose system boundary. 2. Find primary actors and goals through brainstorming ... 3. Define use cases o One use case for each user goal o Name the use case similar to the user goal. • It is a partial domain model • It is drawn using UML class diagram notation, but the domain model is NOT a class diagram for the system to be designed. • It provides a conceptual perspective model that describes the real-world concepts visually. • It does NOT describe the software elements. What is a domain model? • The term ‘domain model’ means a visual representation of real-situation conceptual classes, NOT of software objects. • It is illustrated using a set of class diagrams in which NO operations are defined. • It may show: o Conceptual classes o Associations among conceptual classes o Attributes of conceptual classes • Domain models allow us to understand the domain for which the software system is to be developed. • Lowering the representation gap between o our mental understanding of the domain and our software model for the system that we intend to develop • In some cases, domain models are drawn just to gain understanding of the domain and communicate a rough approximation of key concepts; then they are discarded shortly after creation. • If you want the model to be maintained and updated with discoveries of new concepts, you may consider using a CASE tool; but not always … the software business logic layer tends to give good hints about the domain model. • We do not always try to create software solutions that reduce the “representation gap” … • In some cases, an exact one-to-one mapping may NOT be present, or it may not even be desirable. • As with all things in UP, a domain model is optional, and may not be needed in some cases. How do we create a domain model? 1. Find the conceptual classes 2. Draw them as classes in a UML class diagram 3. Add associations and attributes How do we find conceptual classes? 1-Reuse or modify existing (domain and/or data) models 3- Identify noun phrases in textual descriptions of the domain, such as the use cases for instance. R I S t S e t gaom l r e s e t e r S C C L a a u e l se s d hs t g oi e e m r r e r L i n e I t e m PC C D a a ar e yo sot ms a h d c l e o r c in g p t tt t i o n Rule of Thumb: Description classes - Contain info that describes something else, very common in OO models o If description is not separate from the underlying object, then deletion of the object results in loss of all info about that object Associations - It is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection. An attribute is a logical data value of an object that needs to be remembered o Some attributes are derived from other attributes The usual ‘primitive’ data types o Numbers, characters, booleans Common compound data types o Date, time (or dateTime), address, SSN, phoneNumber, bar codes, etc. o Compound data types may become full class objects in design Will associations be implemented in software? Associations are NOT o A statement about data flows o database foreign keys o instance variables o object connections in a software solution. è It is a statement that a relationship is meaningful in a purely conceptual perspective. • Having said that, many of these associations will be implemented in software as paths of navigation and visibility. System Sequence Diagrams – A system sequence diagram is a UML diagram that shows, for one particular scenario of a use case, the events that external actors generate and their order. o Can help transition from the functional aspect to the OO design systm s back box h enam ecouGd"ueOstemps t sm pe h"a"ndunderineimndyaennspaneedin a aterchapteron eq en e da gam no tton nthe UM L exernalactr o ProcessS ae Scenaro sytem Cashier System makeNew Sae a UM L ooplop moeie]s interacton enteteteDantty framieha b ooeuard e xresso n descrptino am esa gew th endSale etuns)au e parm etrs assoiaed wih h e peviousm esa ge toal wthtaxes ts ana btracion epreseningthe ss tm eventof anabstacton ta t entrng he gnorespresenttion makeP(ammuntt paymentdata by andm edum
More Less
Unlock Document


Only pages 1-3 are available for preview. Some parts have been intentionally blurred.

Unlock Document
You're Reading a Preview

Unlock to view full version

Unlock Document

Log In


OR

Don't have an account?

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


OR

By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.


Submit