Final Prep.docx

18 Pages
Unlock Document

Ryerson University
Information Technology Management
ITM 430
Junlian Xiang

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

Related notes for ITM 430

Log In


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


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.