Opening the PDF files on this page may require you to download
Adobe Reader or an equivalent viewer (GhostScript).
You should distinguish between
[ System Requirements ]
[ Software Requirements ]
in this course. You also need to learn about Functional and Quality requrements (below). The main skill
is writing use cases. You need to know some popular or classic methods.
System Requirements constrain the whole system to do what the client needs. They
are analysed and the results allocated to different components
-- hardware + software + procedures + data + people.
You must be able to show that if each part fits it's requirements then
they will work together to achieve what is required
before we spend any money. We test this by using
walkthroughs, calculations, and inspections.
Notice that a requirement must state a necessary constraint on a part of a system.
System requirements are often high level requirements. They are
broken down to smaller constraints on the individual parts of the system.
are more or less precise descriptions of what software (and sometimes
hardware) has to do plus how well it should do it. They must not say too much
about the technology used or how the software is coded. They give logical picture
of a piece of software.
Software Requirements have to be thought about and specified whenever software
is being developed or maintained. It is especially important with outsourced
software development. As a rough rule, the worse the communications between
stakeholders and developers is (for example outsourced oversees), the more
formal and rigorous your requirements must be.
Well written requirements tend to avoid over-constraining the solution to
problems. They avoid describing the internal structure of the software.
In Software requirements you must carefully distinguish
[ Functional requirements ]
[ non-functional requirements ]
as described below. Both types are important but they have to be dealt with in
very different ways.
Systems Design is not program design
The heart of system design is DATA. In particular, PERSISTENT data.
This is data outside the computer. System design is about what goes on
between and outside computers. It involves specifying the data, the hardware, the people, and the
procedures. It specifies how software behaves but not how it is programmed.
Program design is about what goes on inside a computer.
This is a key distinction.
define what a process or system must do.
They tend to define what happens to the data that flows in and out of the
process. They define the what not the how. For example:
The student is entered in the roster for the chosen section.
In addition to these functional requirements we have
that define how well the process or system carries out its function.
The traditional name is
They demand special care when developing software.
Quality requirements are about how good the software has to be. For example:
Registration must be completed in less than 1 second 90% of the time.
Quality requirements are often about things that must not happen. For example
During registration the student's Id must be protected from sniffers.
Typically you will find both functional and quality requirements in
the initial (high level) requirements. You should learn to parse
As an example:
Grades will be posted securely.
- Functional: Grades will be recorded...
- Nonfunctional: ...securely.
Typical high level quality requirements:
include security, safety, reliability, speed, efficiency, storage space,
ease of use, sustainability,
economy, etc. You can add various costs and the time to develop
and/or maintain a system to these.
Notice that a functional requirement
The teacher can change grades on the system
describe something that must be done but a quality requirement can say that
something must be difficult or even impossible:
A student can not change any grades stored on the system
The architecture of software often depends more on the qualities than
Quality requirements start off as a nice desirable quality
like "User friendly". But they need to be made precise.
They need to be expressed as a set
of measurements that can be made of the final product: "The user can
find out how to cut and paste data on the form without being told", "In a
sample of 10 users, after using the product, 9 of them rate it as
'easy to use' ..." The best quality requirements are based on
national standards. Working out the detailed qualities of a component
so that it is capable of supporting the high level requirements is
a challenging and interesting task.
Similarly, a requirement that "Grades are stored securely" might imply that
nobody, even if they access the data, can determine a student's grade unless
they are the teacher or the student. This is quite difficult to achieve, and
might be watered down in practice so that reading grades without being the
teacher or the student should take several hours of hacking. Another refinement
is: Anyone can read the grades but they can not figure out who each
grade is assigned to.
Use the more modern terminology and talk about "Quality Requirements"!
A common technique in mass marketed software is to document the requirements
in terms of a list of "features" that will be provided. This is largely driven
by marketing. The technique is also used in other situations. Executives
and steering committees like making up a list of the features they want if a new
or updated system. They are a mix of functions and qualities.
They are disorganized and difficult to analyze.
It is possible that this technique contributes to the low quality of much
Functional requirements can be developed top-down. You start with large
scale needs and then decompose them into a set of requirements, which together
achieve the top-level.
DFDs help to do this right.
However, this technique was taken to extremes in the
two decades proceeding the 1990's. As a rule: stop decomposing functions
when you are down to a single program. Then switch to other techniques.
A checklist is a handy tool to avoid forgetting things. So are forms.
So most organizations have a whole set of these to help manage projects.
For example, in the CSUSB CSE School, we require all senior and
graduate projects to follow the IEEE standard "Software Requirement Specification".
[ ../SRS/ ]
It is easy to only specify the processing of perfect data. However
we must also specify what can go wrong, and what to do about it.
Use Cases (next) formalize the need to study the good and the bad
interactions between users and you system.
For the last 10 years Jaccobson's idea of a "use case" has come to dominate
software engineering and development. It organizes the visible behavior
of a system around the needs of the users.
is a description (in text or table) of how a user
uses the system to get something tangible from it.
Low level functions/processes in a DFD tend to be use cases.
A use case describes how a user gets something of benefit
from a system. It can also spell out what can go wrong and what
is done about it. A use case describes the interaction between a user
and the software -- it must not describe what happens inside the software!
It can show the steps taken by the user to get what they want -- but
Use_case::=defines the following,
- Users and other stakeholders
- What they get out of the system -- Goals
- How they try to get what they want -- Scenarios
(End of Net)
A student registers in a class by logging in (if not logged in), selecting an open class,
and saving the new schedule.
Key point: a use cases says who wants what, and how they can get it.
- USER: A student
- GOAL: registers in a class
- SCENARIO: by logging in (if not logged in), selecting an open class,
and saving the new schedule.
Use cases are text documents. Use Cases are not diagrams.
Use case diagrams are just a visual summary of a collection of use cases.
A useful use case diagram shows many users and use cases.
In essence, a use case defines a set of scenarios associated with one user and
one of their needs, but you can add:
- The secondary actors -- involved but not initiating the use case.
- The other stakeholders.
- The value to the user and enterprise.
- The development costs: time and money.
- Other costs: equipment and personnel.
Any word processor or editor can be used to write use cases.
Remember: a use case is written not drawn. Only when you have
several use cases do you need a diagram tool: Dia, Visio, and IBM Rational Rose
all help you draw these diagrams.
name your uses cases
(Strong verb + who) then elaborate the interesting ones.
- A good use case name has a strong verb in it.
The name of a use case should start with a strong verb.
- Start a use case description by naming the primary user who gets something
out of the system.
- Refine use cases a little bit at a time: First the name, then a brief
description, then a casual description, and then elaborate to
a fully dressed one (if it is interesting enough).
- At any time you will have uses cases in all 5 states of description:
Name, Name+User, Brief, Casual, Fully dressed.
- If there are more than half-a-dozen use cases it may pay to give them a
short name or number:
(UC1): student registers in class.
(UC2): Faculty gets a roster for their class.
You can then use hyperlinks to refer to them.
- Writing use cases is a team sport. Get developers and stakeholders involved in
drafting and refining them.
- Do the interesting ones first.
Interesting use cases
are ones with
high value to the stakeholders that also test the architecture of the system.
Interesting use cases are not single steps like "Login", "logout", etc.
- Most systems include some
standard administrative use cases
"start up", "shut down", "back up data", "Maintain Ids", etc.. These are best
done after the interesting use cases since their details depend on
discoveries made when working out how users get things of value out of the system.
Notice that administrative use cases need different designs to ordinary ones.
- Use cases have set of scenarios
are a sequence of steps taken by the user and the system.
The first scenario must be the ideal "sunshine" scenario.
Later scenarios spell out less pleasing scenarios for the user.
But don't get bogged down in all the special ways things go wrong
(power cut, mistyping, interrupted user, network down, ...)until you've
finished the main success scenario. Use the steps in existing scenarios to
create the extensions: ask what can go wrong with each step in turn and
write an alternative sceario that handles the problem.
- Each step should state what the user does and/or what the system responds.
It is OK for a step to be the name of a fairly complex procedure as long as
the name makes it clear what is achieved. Define the details later.
If (and only if) a step is interesting and turns up in several use cases
you can document it as a use case and - - <<include>> - - - > It.
- The steps must not mention how the system does something.
However, a step can refer to actions involving secondary actors or
to data that is held in the system data base.
Avoid describing internal coding details of algorithms and objects.
Avoid user interface details. Keep the actions logical rather than physical.
The steps must not describe the hardware, format, or look-and-feel of the user-interface.
- Make sure you
store use cases
so that they are easily found, edited, and used.
For example: Put use cases on a project web site with a search engine. Recall
that use cases are hyper-text -- find a repository that searches text files.
Have back up copies and plans.
Keep track of different versions. With a team, use tools to handle
versions and revisions.
Your CSE home directory is OK for your own work but it is not designed to make
Both Google Docs and Drop Box are convenient places in the cloud for student projects.
- You can state that a sequence of
steps can be repeated
-- "The user inputs selects several items to put in the basket."
You can have
simple conditional step in a scenario
-- "If the user has a Club Card they input its number and the system notes the extra discount"
-- but don't write
nested if-then-elses. Handle these by introducing an extension or
If the sequence/logic starts getting complicated then you may need to use
an activity diagrams etc.
[ r1.html ]
to sort it out.
- Delay drawing a use case diagram until you need a visual summary of all the things
a piece of software can do for its user. See below...
With a strong verb!
(Name): Terse one paragraph description of who does what to get what.
(nightmare use case): The president of the USA can login, identify himself, and start World War III.
(Process my Email): A student can login, see the headers of Email
messages and then read, delete, reply to, and forward a message.
(Name): short name
(Main Success Scenario): one paragraph.
(Alternative scenario 1): if ...., one paragraph
(Alternative scenario 2): if ...., one paragraph
- Name: Guest registers on system.
- Main: A guest can register with the system by giving certain details, supplying
a system "handle", and a password(twice). The system responds by reflecting the
information back to the guest(but not the password). The guest confirms the data
and is allowed
access to it via the usual login.
- alternative 1: If the "handle" is already in use the guest is asked to change their
- alternative 2: If the two passwords are not equal the guest must re-input them.
. . . . . . . . . ( end of section Casual) <<Contents | End>>
This is a long document with several sections. Here is a list of sections.
Some are optional. Some can be repeated.
- Name -- May include a unique Id.
- Actors -- Main actors and other participants
- Stakeholders -- other people and systems that do not participate but have a stake
in the success of the use case.
- Description -- Brief Format Description
- Main Success Scenario -- sequence of numbered steps achieving the primary actor's needs.
- Alternatives & Extensions -- scenarios for the less successful or more complex cases.
Note: number alternatives to show which in which main flow step they can happen.
"1a", "1b", "1c" are alternatives to "1", "2a" to "2", "2-5a" can occur in any step from 2 to 5 inclusively,
and "*a" can happen in any step.
- Preconditions -- what can be assumed to be true before use case starts.
Example: user must be logged in.
- Post Conditions -- what must be guaranteed to be true after.
Example: student is enrolled in class.
- Special Requirements -- reliability, speed, cost, ...
|System||OSS: Online Shopping System.
|Name||UC12: Validate credit card
|Actors||Prime: Customer, Secondary: Credit card company
|Other Stakeholders|| Client, government -- sales tax.
|Description||The customer supplies a credit card and it is validated.
|Main Success Scenario
- Customer enters credit card number and expiration date
- System verifies card with credit Card company
- System sends authorization message to the customer
In step 2, if the credit card company rejects card,
system sends rejection message to user.
In step 2, if the credit card company does not respond within 10 seconds,
- Tell the user of the delay.
- Repeat verifying the card.
In any step, the client does not respond after 30 minutes,
cancel the transaction.
In any step, if there is a power failure.... TBD
|Precondition||Customer has selected at least one item and has
proceeded to checkout area.
|Post condition||Credit card information has been validated.
Customer can continue with order.
|Assumptions||User has a credit card
|Special Requirements||Security -- No way for customer data to be sniffed.
[ Use%20case%20POS.pdf ]
- The use case is not named with a strong active verb. "Authentication" is an error.
"Authenticate" is better.
- The use case does not define a tangible and desirable goal for its user.
"Authenticate" is probably too small a goal. "Enroll in class" is better.
- There is no main or sunny day scenario.
- The use case is too high level. It should define a user and something specific
that they need.
- The use case is too small/low level to be useful to any body. Try the
"Hey mom, I just ___ " test.
- Too much predictable detail.
- Including any physical or technical details of how a use case is coded: example
mentioning the DBMS or interface technology. These are going to change. Keep use cases
logical or essential.
- Attempting to complete one use case before starting on others. Start with
a list of use cases and select one to work on, then move on to another.
- Missing descriptions but a nice diagram.
- Drawing a diagram with only one use case.
- Trying to put the whole system in one use case.
- Copying use cases from other projects that are not relevant.
A user story can be anything that the user desires of a system, such as
it being able to run 24/7/365. All brief use cases are user stories.
But some user stories are not use cases. For example:
- The system will be user friendly.
is a story but not a use case. This is a high-level, fuzzy, nonfunctional
requirement. It needs refinement: who is the user? what do they find to be friendly?
Further: how do test "user friendliness"? Once we can express the nice, warm, fuzzy term
as an objective test -- then we are getting close to producing solutions that achieve what
the stake holders want. Alternatively we may identify and area that need research --
what do the mean by "user friendly"?
A scenario only becomes a use case when you add a description of what the
user gets out of the scenario (or what he user was trying to get out of it).
Note: KISS in CSE557. We do the complex diagrams and formats in CSE375.
Develop use cases using text processors...
Use the Casual Format use case in this class:
Keep use case diagrams very simple. Here are the four synbols you need:
actor, communication, system, use case.
DON'T put steps on a diagram! For example: "login" is a common first step
in many scenarios. Do not show "login" as a separate use case. Show it as
a step, or document the need for "login" as a pre-condition for the use case.
Don't go overboard on drawing use case diagrams. Keep them simple.
Use cases are about writing not drawing.
Use case diagrams show communication between actors and use cases. Actors do not
communicate with out a use case. Use cases do not communicate under any circumstance.
The use case diagram is a good place to "boiler plate" the administrative use cases.
They are always there but don't help you analyse the situation. It is best to put them off
until you've analysed the interesting use cases.
There are notations for showing common scenarios shared between several
use cases (<<include>>) and for showing extended (alternative) use cases.
Please avoid them, if you can, in this class.
The following part of a use case diagram shows connections
between use cases: Adding classes includes logging in and logging out.
So does getting a class roster.
It also shows the special alternative case of trying to add a full class.
This is called an "extension" and is expressed as extending particular
steps in the basic use case.
These are the only connections between use cases that you should draw.
The diagram does not show the "Special case of" arrow. This
is rarely used.
When you want to present your ideas and have more than one use case or user.
You need one in complex projects when
you have a dozen or more use cases and you notice some common
They make a nice poster for the developers work space. Even better put it on a
board next to an ERD and change it each iteration.
The simplest perfect case when a user does the right things, the
system has the right resources and the user gets what they wanted.
There is no ideal number. Big projects have many
use cases and small projects have a few (simple) use cases.
In fact the number
of the total number of scenarios indicates how big and expensive a project will
All successful requirements specification processes involve the stakeholders in the process.
A straightforward project can follow the traditional sequence:
- Analyze situation
- Design System
- Specify Software Requirements -- in detail, top down, ...
- Implement Software
- Test and Improve Software
- Unit tests -- inside software
- Acceptance tests of pieces of software
- Integration tests at the system level
- Performance tests/Benchmarks
- Training, initial data, and cut over.
- Operate and Maintain System
In the above the requirements must be complete and correct before
This is similar to
Joint Application Design involves the users and other stakeholders
in the process of designing systems and specifying requirements. Typically
the developers and the stakeholders have meetings. And the meeting generate
requirements for the software being developed. The advantage is that
the stakeholders have a strong chance of getting what they want.
they can also run a large project into the ground by producing requirements
faster than they can be coded.
the clients continuously produce new and corrected requirements
faster than the developers can implement them JAD breaks down. Some form
of incremental delivery and a system to control the
rate of change of requirements is almost a necessity when using JAD
with large systems.
The two above techniques assume that the stakeholders and the developers have
all the knowledge that they need to come up with a better system. This is
not always true. We often need to do some research before we develop software.
One response to the need to learn about the solutions and needs is the RAD
method of prototyping.
The aim is to give stakeholders what they want quicker.
RAD relies on tools that let's developers throw software together
Prototypes define requirements and are then thrown away. They are
developed quickly with no attention to other qualities. They are not
documented, tested, or designed to be maintained. RAD was fashionable in the
1990's but is getting less press these days.
These prototypes are best used when you think that people don't really
know what they need.
They are also very useful for sorting out user interfaces: you can show
two versions of the GUI and ask which is best? User interfaces need to evolve.
So it is best place the user interface a separate but well-crafted part of
Agile methods stress people and providing value to the stakeholders.
Instead of prototypes they provide a sequence of quick high-quality,
high value, useful, iterations.
Instead of meetings they tend to have an informal work place where everybody
can hear what is going on.... complete with on-site users.
They also stress shared code and documents. They often stress doing
detail work in pairs: pairing. Some have "stand up meetings".
Instead of paper work documentation they stress face-to-face communication,
test plans, chalkboards or white boards, posters,
3-by-5 cards, sticky notelets, and code. They want documentation to be
"Just good enough". However -- "Don't let the sun set on bad code".
They stress excellent source code and 100% compliance with tests
for programs -- from the first iteration onward. They stress automating
routine tasks -- like testing.
Indeed most of them are
"Test Driven Development" -- they write the tests before they write the code.
Thus the software requirements specification for a project is a set of tests!
They often include an explicit "code refactoring" process that improves
the quality of working code without breaking any tests. This counters
the well known tendency of code to "rust" as small changes are made
to it. In refactoring a series of small changes are made to the code that are
sure to not break it. Each is followed by a quick retest. Step by step the
code becomes clearer and better structured.
The key difference between RAD and Agile development is that
one uses prototypes and the other iterations.
XP is a very rigorous agile method -- it works in terms of 1 week iterations
and 100% test
driven coding. The whole programming team must work in a shared area
and must involve a
Requirements are expressed as user stories written on cards.
The week starts with a negotiation to choose the cards that
will be tackled in that week. The user writes acceptance tests, the programmers
work on the code. All the code is open to all the programmers to work on.
But programmers always work in pairs: one types and the other thinks and comments.
The week ends in refactoring the code so that it remains easy to understand
and easy to maintain.
An iteration is a high quality and usable subset of a project.
One iteration is also a part of the development time that carries out
a more or less complete Software Development Life Cycle for a few functions
at a time:
The RUP is a family of similar processes.
RUP can be tuned to operate like a traditional SDLC or an agile process.
We will use something like this in the next class CSE375.
- Analyze a little, Design a little, Code a little, Test a little.
Each iteration is well made and documented but
doesn't meet all requirements, yet.
A prototype is often incomplete and nearly always of low quality.
As a rule it is harder to put quality into bad software than it is to
add features to good software. Some call them "throw-away" prototypes.
They often are.
A high quality prototype program is best called an iteration
and in some sources it is called an evolutionary prototype.
In your dreams!
RAD means low quality prototypes ... and
low quality code makes
Only in small projects -- In My Humble Opinion.
In my experience the prototype tends to become a nightmare.
For example see
[ ../tools/mth2html.txt ]
(Mad laughter echoes from the dark dusty dungeon of deadly code)
The different methods do have different personalities -- even if they share
thought: "Involve the stakeholders in the process". In fact the
first decision you need to involve others in -- is in selecting the
method: Have they the time and resources for JAD meetings? Would they
prefer to see demos of the product every now and then? Would they be
willing to send a representative to live and work as part of the
development team (as in XP)? ...
I still like the classic approach: map out the current system and look
for a set of processes and data stores that could work better. Think in
terms of doing surgery to the living enterprise:
"What organs need replacing?". As you talk to people take note of
where the current system hurts. Be ready to brainstorm.
Then "drill down" into the details at the boundaries of the old and new.
Don't forget to involve the stakeholders and get your ideas reviewed.
JAD gives people what they want -- but occasionally JAD
tends to lead to wasting time and money on a system that does not work.
Ideally as each requirement comes out of the JAD team it should have a price
tag attached to it, and a Change Control Board (or equivalent) decides
if the enterprise can afford the price for the new feature/quality/...
I don't have any data! My feeling (from reading 5 or 6 magazines
on software development each month) is that RAD getting unpopular.
Indeed I think we are seeing mixed methods where a JAD meeting is
used with a PC prototyping system and projector to rapidly
develop a mock up system -- RAD.
. . . . . . . . . ( end of section Methods of Requirements Development) <<Contents | End>>
[ s6083.htm ]
paper is in the IEEE Digital Library. You can read on campus, via the library proxy,
or if you are a member of the IEEE-CS.
The following should be read before you get into a real project.
There has been a lot of research and thought about this type of requirement
and one result has been some complex models, for example
[ column4 ]
to see a list of things that a quality requirement should include
plus some UML pictures. Focus in on the checklist (part 3) of
Uncontrolled features and JAD can ruin a project.
[ 000980.html ]
in the Coding Horror series for example feature lists, and how
"creeping featuritis" leads to buggy software.
A classic example was the FBI VCF project but the page on it
[ Joint_application_design ]
for a good definition and description.
There have been several books published on JAD
- Ellen Gottesdiener, Requirements by collaboration: workshops for defining
needs, Addison-Wesley Longman Publishing Co., Inc., Boston MA 2002. ISBN
[ http://www.ebgconsulting.com/ ]
- Bodker, Kensing and Simonson, Participatory IT design, MIT Press 2004 QA76.9 W88B65 2004
- Courage and Baxter, Understanding your users, Morgan Kaufman2005 QA76.9 H85 C69 2004
She is an author and consultant
[ ellen in about ]
Interesting question. The earliest reference in my collection of publications[
] on software development is to articles on the FAA's "Advanced Automation Program" from
But -- the articles describe "joint application design" with their users
without once mentioning "JAD" by name. I guess that I already knew the term from other
sources and attached it to this example.
JAD is explicitly mentioned in a special issue (Vol 36 no 4) of the
"Communications of the Association for Computing Machinery" on "Participatory Design".
An article (page 41) credits IBM in the 1970's as the source. This article
also tracks the evolution of the JAD method... The whole issue
(looking back at it from 13 years later) is full of ideas that are
now part of the mainstream, see
[ toc.cfm?id=153571&coll=portal&dl=ACM&type=issue&idx=J79&part=periodical&WantType=periodical&title=Communications%20of%20the%20ACM&CFID=3065872&CFTOKEN=95778283 ]
(the special issue on Participatory Design = PD).
[ Rapid_application_development ]
for history etc.
Here are half-a-dozen references to publications of experiences
with various kinds of prototypes:
[ http://www.agilealliance.com/ ]
For more see
[ RUP ]
on the Wikipedia.
CSE375 is all about UP which is a non-proprietary version of RUP.
[ ../cs375 ]
Usage Scenarios are simpler and more precise than use cases. They rapidly get
to the heart of how the software and its users interact.
However they are not widely used.
[ usage_scenarios.html ]
[ Use_cases ]
for a good description.
[ systemUseCase.htm ]
Proposal made to Hewlet-Packard
[ use_case.pdf ]
(Full disclosure -- I worked with the author 40 years ago).
Example from Virginia Tech
[ usecases-ex1.html ]
[ Use_cases ]
History and Advice
[ Use+cases,+ten+years+later ]
Alexander Cockburn: writing effective use cases
Martin Fowler: UML distilled
You can find the UML
notations in Fowler and the UML manuals. See
[ Use_case_diagram ]
If you have time or the tools you can make the use case diagram a MAP
in an HTML page and link the bubbles to their definitions
[ UseCases.html ]
for an slightly over the top example.
- Here are some easily found examples of diagrams
[ images?q=use+case&hl=en ]
but most are more complex than we need for CSE557!
- What is a use case?
- What are the levels of description of a use case?
- Give examples of a requirment and parse it into functional
and quality parts.
- How does a non-functional or quality requirement differ from a functional requirement?
- Compare and contrast: functional and quality requirements.
- Compare and contrast: use case and scenario.
- Compare and contrast: use case and user story.
- Compare and contrast: use case diagram vs each of these in turn: DFD, ERD, and Activity Diagram
- List the components of a fully dressed Use case.
- Name half-a-dozen high level (fuzzy) quality requirements.
- Take a given high level non-functional requirement and propose a partial test
for the requirement.
- How use case diagram, use cases, DFDs, ERDs, and other artifacts fit into a
strict systems development life cycle?
- What do you say to a new recruit who refers to a use case diagram and calls it a use case?
- Correct a given use cases with errors...
- Write a use case that fits in as part of any of the requirements described below
[ 20040223ChouFlyer.pdf ]
[ 20040308ChinpanichFlyer.txt ]
[ 20040318RohiniReddy.txt ]
[ 20050315HumairaRahim.txt ]
[ 20050322AmitDhir.txt ]
[ 20050321JuyongJeong.txt ]
[ 20050509RayYang.txt ]
- In the UML, as taught in this class, which is the node, the entity, the use case, and the
activity in the diagram below.
- What connections are allowed (in CSE557) between use cases in a use case diagram? Between actors? Joining actors
to/from use cases?
- What does JAD mean?
- How do you do a JAD Meeting?
- What does RAD mean?
- How does an iteration differ from a prototype?
. . . . . . . . . ( end of section Requirements and Use cases) <<Contents | End>>
TBA::="To Be Announced".
TBD::="To Be Done".
Notes -- Analysis
[ a1.html ]
[ a2.html ]
[ a3.html ]
[ a4.html ]
[ a5.html ]
[ c1.html ]
[ c2.html ]
[ c3.html ]
[ d1.html ]
[ d2.html ]
[ d3.html ]
[ d4.html ]
[ r1.html ]
[ r2.html ]
[ r3.html ]
[ project0.html ]
[ project1.html ]
[ project2.html ]
[ project3.html ]
[ project4.html ]
[ project5.html ]
[ projects.html ]
[ F1.html ]
[ F2.html ]
[ F3.html ]
[ about.html ]
[ index.html ]
[ schedule.html ]
[ syllabus.html ]
[ readings.html ]
[ review.html ]
[ glossary.html ]
[ contact.html ]
[ grading/ ]