[Skip Navigation] [CSUSB] / [CNS] / [Comp Sci & Eng Dept] / [R J Botting] /[CS372 Course Materials] /r2.html [r2.txt(Text)] [Search ] Tue Nov 10 13:43:00 PST 2009
[About] [News] [Schedule] [Syllabus] [Glossary] [Contact] [Grades]
Readings Analysis [1] [2] [3] [4] [5] Choices [1] [2] [3] Data [1] [2] [3] [4] Requirements [1] [2] [3]
[Review] Field Trips [1] [2] [3] Project Iterations [1] [2] [3] [4] [5]
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).

Contents

    Requirements and Use cases

      Introduction to Requirements

       You should distinguish between [ System Requirements ] from [ Software Requirements ] in this course.

      System Requirements

      These constrain the whole system to do what the client needs. They should be broken down and the results allocate to different components in a systems architecture -- hardware + software + procedures + data + people. Given that each part fits its requirments then you should be able to argue that they will work together to achieve what is required.

      Notice that a requirement must state a constraint on a part of a system. System requirements are often high level requirements. We often use outlines to describe how the constraints on the whole system is broken down into a collection of constraints on the parts of the system.

      Software Requirements

      Requirements are more or less precise descriptions of what software (and sometimes hardware) has to do plus how well it should do it. 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. The avoid describing the internal structure of the software.

      Be very careful to learn the difference between [ Functional requirements ] and [ non-functional requirements ] before moving on the modern way of organismic requirements -- use cases.

      Before Starting Requirements

      Systems Analysis and Systems Design.
      1. Understand the current situation [ a1.html ] (enterprise) [ a2.html ] (systems) [ a3.html ] (architecture) [ a5.html ] (diagrams) [ a6.html ] (text models)
      2. Select a solution and checking feasibility and value to the enterprise [ c1.html ]
      3. Break down solution into components [ c2.html ]
      4. Plan an initial schedule [ c3.html ]
      5. Define a data base [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ]
      6. Deploy the ideal logical solution into hardware -- (proposed physical model).
      7. Order the hardware!
      8. Define what the software components do -- rules and scenarios.

      Note: the requirements discipline covered in this part of the course may change any of the decisions made previously. But it is easier to specify software when you (for example) know the data it can use.

      Systems Design is not program design

      1. The heart of system design is DATA.
      2. In particular, PERSISTENT data.

        Main tasks in Systems Design

      3. Architecture::= Programs, data bases, modules, functions, components.

        Process:

        1. Review Requirements with stakeholders
        2. Review models of current system and situation.
        3. New Logical model + a strategy: iterations, components, ...
        4. Design systems architecture
          1. User Interfaces -- Now and in the future
          2. Non-Functional requirements
          3. Inputs, Outputs, and Reports
          4. Data -- enter quickly and verify, automate?, control access, report changes, enter once.
          5. Components/programs -- specify requirements

        5. Present to stakeholders etc.
        6. Get buy-in for software development

      Note: All projects are risky and different methods of systems analysis have different risks. In CSCI375 we will take a highly unified approach which cycles rapidly through the various phases.

      Non-functional vs Functional requirements

      This is a key distinction. Functional requirements 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 quality requirements that define how well the process or system carries out its function. The traditional name is non-functional requirements for these. They demand special care when developing software. Quality requirements are about how good the software has to be. For example: 

       If possible to register in class then this must happen with in a second.

      Quality requirements are often about things that must not happen. For example 

       During registration the students id must be protected from sniffers.

      Typically you will find both functional and quality requirements in the initial (high level) descriptions. As an example: 

       Grades will be posted securely.

      Typical quality requirements: security, safety, reliability, speed, efficiency, storage space, economy, etc. You can add various costs and the time to develop and/or maintain a system.

      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 needed qualities than the function specifications.

      Typically quality requirements start off with 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 most reliable quality requirements are base on national standards.

      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 student should take several hours of work. Another refinement is: Anyone can read the grades but they can not figure out who each grade is assigned to.

      Technique -- List Features

      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 make up a list of the features they want a new or updated system to provide. They are a mix of functions and qualities.

      It is possible that this technique contributes to the low quality of much software.

      Technique -- Top-down Functional decomposition

      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.

      Tool -- Checklists and Forms

       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 CSCI department we require all senior and graduate projects to follow the IEEE standard "Software Requirement Specification". [ ../SRS/ ]

      Method -- Traditional System Development Life cycle -- SDLC -- Reminder

      A straightforward project that can follow the traditional sequence:
      1. Analyze situation
      2. Design System
      3. Specify Software Requirements

      4. Implement Software
      5. Test and Improve Software
        • Unit tests -- inside software
        • Acceptance tests of pieces of software
        • Integration tests at the system level
        • Performance tests/Benchmarks
      6. Training and cut over.
      7. Operate and Maintain System

      In the above the requirements must be complete and correct before implementation starts.

      Method -- JAD -- Joint Application Design

      This is similar to Participatory Design. 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.

      However, they can also run a large project into the ground by producing requirements faster than they can be coded. When 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.

      Method -- RAD -- Rapid Application Development

      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 a reliable assumption. We often need to do some research before we development. 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 quickly. 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.

      These prototypes are best used when you think that people don't really know what is needed. They are also very useful for sorting out user interfaces: you can show two versions of the GUI and ask which is best? RAD was fashionable in the 1990's but is getting less press these days.

      As a rule user interfaces need iterative development. But it is still better to make the user interface a separated but well-crafted part of the software.

      How do you decide on the method JAD, RAD, ...

      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)? ...

      What is the best way to start the design of a system

       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.

      What are the advantages and disadvantages of JAD

      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/...

      Which is used most in the workforce -- JAD or RAD

      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.

      Agile Methods

      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.

      Iterations vs Prototypes

        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: 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.

        Can a prototype be incomplete

        Yes.

        Can a prototype be of low quality

         They often are. A high quality prototype program is best called an iteration and in some sources it is called an evolutionary prototype.

        Can RAD prototypes evolve into better programs

         In your dreams. RAD means low quality... and low quality code makes evolution difficult.

        Does a special RAD language like DELPHI give prototypes that can be converted into a final product

         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)

      A Family of Methods -- RUP -- Rational Unified Process

       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 CSCI375.

      Requirements Tool -- Use cases

      A use case is a description (in text or table form) 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.

      Definition of Use Case

      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 not format/layout/media.

    1. Use_case::=defines the following,
      Net
      1. Users -- and other stakeholders
      2. What they get out of the system -- Goals
      3. How they can try to get what they want -- Scenarios

      (End of Net)

      Key point: a use cases says who wants what, and how they can get it. Use cases are text documents. Use Cases are not diagrams. Use case diagrams are just a visual summary of a collection of 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:

      1. The secondary actors -- involved but not initiating the use case.
      2. The other stakeholders.
      3. The value to the user and enterprise.
      4. The development costs: time and money.
      5. Other costs: equipment and personnel.

      Tools for use cases

       Any word processor or editor can be used to write use cases. Remember: a use case are written not drawn.

      The diagrams can be done by most tools: Dia, Visio, and IBM Rational Rose.

      Hints on use cases

      1. First name your uses cases (Strong verb + who) then elaborate the interesting ones.
      2. Start a use case description by naming the primary user who gets something out of the system.
      3. 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).
      4. At any time you will have uses cases in all 5 states of description: Name, Name+User, Brief, Casual, Fully dressed.

      5. 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.

      6. Writing use cases is a team sport. Get developers and stakeholders involved in drafting and refining them.
      7. Do the interesting ones first. Interesting use cases are ones with high value to the stakeholders that need test the architecture of the system. Interesting use cases are not single steps like "Login", "logout", etc.

      8. The name of a use case should start with a strong verb.
      9. Most systems include some standard administrative use cases. Do these later. Examples: "start up", "shut down", "back up data".

      10. Use case are set of scenarios starting with the ideal "sunshine" scenario.
      11. Later scenarios spell out less pleasing scenarios for the user.
      12. Scenarios are a sequence of steps taken by the user and the system.
      13. 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.
      14. 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.

      15. 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 a hyper-text -- find a repository that searches text files.
      16. Keep track of different versions. With a team, use tools to handle versions and revisions.
      17. Keep a back up copy of all use cases.
      18. Don't get bogged down in all the special ways it can go wrong until you've finished the main success scenario.

      19. You can state that a sequence of steps can be repeated. Don't write nested if-then-elses in a scenario. Handle branches by introducing an extension or alternate scenario. If the sequencing starts getting complicated then you may need to use an activity diagram to sort it out.

      20. 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.
      21. Keep use case diagrams very simple

        Keep Use Case diagrams Simple

      22. 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.
      23. There are notations for showing common scenarios shared between several use cases and for showing extended (alternative) use cases. Please avoid them in this class and in most real projects.

      Three Formats for Use Cases -- Brief -- Casual -- Fully-dressed

        Remember -- the name comes first

        Brief Format Use Case
        (Name): Terse one paragraph description of who does what to get what.

        Examples:


          (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.

        Casual Format Use Case


          (Name): short name
          (Main Success Scenario): one paragraph.
          (Alternate scenario 1): if ...., one paragraph
          (Alternate scenario 2): if ...., one paragraph

          Example

          1. Name: Guest registers on system.
          2. 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.
          3. If the "handle" is already in use the guest is asked to change their "handle".
          4. If the passwords are not equal the guest must re-input them.

        . . . . . . . . . ( end of section Casual) <<Contents | End>>

        Fully Dressed format

        1. System
        2. Name -- May include a unique Id.
        3. Actors -- Main actors and other participants
        4. Stakeholders
        5. Description -- Brief Format Description
        6. Main Success Scenario -- sequence of steps achieving the primary actor's needs.
        7. Alternatives & Extensions -- scenarios for the less successful or more complex cases.
        8. Preconditions -- what can be assumed to be true before. Example: user must be logged in.
        9. Post Conditions -- what must be guaranteed to be true after. Example: student is enrolled in class.
        10. Assumptions
        11. Special Requirements -- reliability, speed, cost, ...

        Example of a fully dressed use case
        Table
        SystemOSS: Online Shopping System.
        NameUC12: Validate credit card
        ActorsPrime: Customer, Secondary: Credit card company
        Other Stakeholders Client
        Descriptionthe credit card validation process
        Main Success Scenario
        1. Customer enters credit card number and expiration date
        2. System verifies card with credit Card company
        3. System sends authorization message to the customer

        Alternative 1 In step 2 if the credit card company rejects card, system sends rejection message to user.
        Alternative 2
          In step 2 if the credit card company does not respond within 10 seconds,
        1. Tell the user of the delay.
        2. Repeat verifying the card.

        Alternative 4 In any step, the client doesn't respond after 30 minutes, cancel the transaction.
        Alternative 5 In any step, if there is a power failure.... TBD
        Alternative ...-
        PreconditionCustomer has selected at least one item and has proceeded to checkout area.
        Post conditionCredit card information has been validated. Customer can continue with order
        AssumptionsNone
        Special RequirementsSecurity -- No way for customer data to be sniffed.

        (Close Table)

      Common Use Case Errors
      1. The use case is not named with a strong active verb. "Authentication" is an error. "Authenticate" is better.
      2. The use case does not define a tangible and desirable goal for its user. "Authenticate" is probably too small a goal. "Enrol in class" is better.
      3. The use case is too high level. It should define a user and something specific that they need.
      4. There is no main or sunny day scenario.
      5. Missing descriptions but a nice diagram.

      User Stories are not Use Cases

       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:
      1. 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?

      A Scenario is less than a use case

       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 CSCI372. We do the complex diagrams and formats in CSCI375. Develop use cases using text processors... Use the Casual Format use case in this class:

      Use Case Diagrams

      Don't go overboard on drawing use case diagrams. Keep them simple. Use cases are about writing not drawing. 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.

      Part of a use case diagram.

      When should we use a UML use case diagram

      When you want to present your ideas.

      You need one in complex projects when you have a dozen or more use cases and you notice some common patterns developing.

      Questions

        What is a Sunshine scenario

        The simplest perfect case when a user does the right things, the system has the right resources and the user gets what they wanted.

        How many use case scenarios should be included in a project

        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 be.

      Online Resources

        Story -- Think outside the box

         [ s6083.htm ]

        Enrichment -- Real Quality Requirements

         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 the article.

        Creeping Featuritis and Death by JAD

         Uncontrolled features and JAD can ruin a project.

        See [ 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 has vanished.

        Details on JAD

        See [ JAD ] for a good definition and description.

        There have been several books published on JAD

        1. Ellen Gottesdiener, Requirements by collaboration: workshops for defining needs, Addison-Wesley Longman Publishing Co., Inc., Boston MA 2002. ISBN 0-201-78606-0 $44.99 [ http://www.ebgconsulting.com/ ]
        2. Bodker, Kensing and Simonson, Participatory IT design, MIT Press 2004 QA76.9 W88B65 2004
        3. Courage and Baxter, Understanding your users, Morgan Kaufman2005 QA76.9 H85 C69 2004

        Who is Ellen Gottesdiener

         She is an author and consultant [ index.asp ]

        Who invented JAD

         Interesting question. The earliest reference in my collection of publications[ JAD ] on software development is to articles on the FAA's "Advanced Automation Program" from 1987. 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).

        RAD on the Wikipedia

        See [ Rapid_application_development ] for history etc.

        Real world examples of using a prototype

         Here are half-a-dozen references to publications of experiences with various kinds of prototypes: [CarrollCarrithers84] [Cerietal88] [Cloyd01] [Constantine00] [GordonBieman95] [KamataYoshizawa00] [KeilCarmel95] [Morales00]

        The Agile Alliance

         [ http://www.agilealliance.com/ ]

        RUP

         For more see [ RUP ] on the Wikipedia.

        CSCI375 is all about UP which is a non-proprietary version of RUP. See [ ../cs375 ] for details.

        Alternate Technique -- Usage Scenarios

        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. See [ usage_scenarios.html ] for more.

        Use cases on the Wikipedia

         See [ Use_cases ] for a good description.

        Use case Resources on the Web

         Sensible introduction: [ 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 ]

        Wikipedia: [ Use_cases ]

        Books on Use Cases

        Alexander Cockburn: writing effective use cases

        Martin Fowler: UML distilled

        UML diagrams on the web

        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 See [ UseCases.html ] for an slightly over the top example.

      1. Here are some easily found examples of diagrams [ images?q=use+case&hl=en ] but most are more complex than we need for CSCI372!

      Review Questions on Use Cases and Requirements

      1. What is the purpose of requirements and what goes before them.
      2. What does JAD mean ?
      3. What does RAD mean?
      4. How does an iteration differ from a prototype?
      5. How does a non-functional requirement differ from a functional requirement?
      6. Compare and contrast: functional and nonfunctional requirements.
      7. Compare and contrast: use case and scenario.
      8. Compare and contrast: use case and user story.
      9. Compare and contrast: use case diagram vs each of these in turn: DFD, ERD, and Activity Diagram
      10. List the components of a fully dressed Use case.
      11. Is a use case a diagram or a piece of text?
      12. Name half-a-dozen high level (fuzzy) non-functional requirements.
      13. Take a given high level non-functional requirement propose a partial test for the requirement.
      14. How use case diagram, use cases, DFDs, ERDs, and other artifacts fit into a strict systems development life cycle?
      15. Correct a given use cases with errors...

      16. Write a use case that fits in as part of any of the requirements described below for: [ 20040223ChouFlyer.pdf ] [ 20040308ChinpanichFlyer.txt ] [ 20040318RohiniReddy.txt ] [ 20050315HumairaRahim.txt ] [ 20050322AmitDhir.txt ] [ 20050321JuyongJeong.txt ] [ 20050509RayYang.txt ]
      17. In the UML as taught in this class, which is the node, the entity, the use case, and the activity in the diagram below.

        [A:Box, B:Cube, C:rounded rectangle, D:Oval]

    . . . . . . . . . ( end of section Requirements and Use cases) <<Contents | End>>

    Abbreviations

  1. TBA::="To Be Announced".
  2. TBD::="To Be Done".

    Also see [ glossary.html ] for more special abbreviations and phrases.

End