Case Study

Case Study
4.5.1. Vision Document
A vision document contains more than those things needed for the modeling effort. It also contains financial and scheduling pertinent information. The following sections are those parts of the Vision Document spelled out in Section 4.3.1, “Vision Document” above. In practice this format need not be followed religiously, but is used here for consistency.
4.5.1.1. Summary
The company wishes to produce and market a line of ATM devices. The purpose of this project is to produce the hardware and the software to drive it that are both maintainable and robust.
4.5.1.2. Goals
To produce better designed products based on newer technology. Follow the MDA philosophy of the OMG by producing first a Platform Independent Model (PIM). As current modeling technology does not admit of maintaining the integrity of the connection between the PIM and Platform Specific Models (PSMs), the PIM will become comparatively stable before the first iteration of the PSM is produced. The software platform will be Java technology. The system will use a simple userid (from ATM card) and password (or PIN) mechanism.
4.5.1.3. Market Context
Equipment currently on the market is based on older technology for both hardware and software. This technology has not reached the end of its useful life, making it unlikely that the vendors of that gear are going to update it in the near future. On the other hand newer technology is available that would put us at a competitive advantage if implemented now.
4.5.1.4. Stakeholders
Among the stakeholders for this system are the Engineering Department, the Maintenance Department, and the Central Computer Facility. The full list of these stakeholders and the specific individuals representing them are.
Engineering. Bunny, Bugs
Maintenance. Hardy, Oliver
Computer Facility. Laurel, Stanley
Chief Executive Officer. Hun, Atilla The
Marketing. Harry, Oil Can
4.5.1.5. Key Features
Cash deposit, cash withdrawal, and account inquiries by customers. Customers include people who have accounts at the owning bank as well as people who wish to make withdrawals from accounts in other banks or from credit card accounts.
Maintenance of the equipment by the bank's engineers. This action may be initiated by the engineer on a routine basis. It may also be initiated by the equipment that can call the engineer when it detects an internal fault.
Unloading of deposits and loading of cash by officials of the local bank branch. These actions occur either on a scheduled basis or when the central computer determines that the cash supply is low or the deposit receptacle is liable to be getting full.
An audit trail for all activities will be maintained and sent periodically to the bank's central computer. It will be possible for the maintenance engineer to save a copy of the audit trail to a diskette for transporting to the central computer.
Both dialup and leased line support will be provided. The ATM will continue to provide services to customers when communication with the central computer is not available.
4.5.1.6. Constraints
The project must be completed within nine months. It must cost no more than 1,750,000 USD excluding production costs. Components may be contracted out, but the basic architecture as well as the infrastructure will be designed in house. Close liaison must be maintained between the software development and the design, development and production of the hardware. Neither the hardware nor the software shall be considered the independent variable, but rather they shall be considered equal.
4.5.1.7. Appendix
The following are the actors that directly support this vision. Additional actors may be identified later that are needed to support this or that technology. They should not be added to this list unless they are deemed to directly support the vision as described in this document.
Central Computer
Customer
Local Branch Official
Maintenance Engineer
The following are the use cases that directly support this vision. Additional use cases may be identified later that are needed to support this or that technology or to support the use cases listed here. They should not be added to this list unless they are deemed to directly support the vision as described in this document.
Audit
Customer Uses Machine
Maintain Machine
4.5.2. Identifying Actors and Use Cases
For the ATM case study, we will elaborate on the examples in Section 4.3, “Output of the Requirements Capture Process”, Figure 4.4, “Use case diagram for an ATM system showing include relationships.” and Figure 4.5, “Use case diagram for an ATM system showing an extend relationship.”, and progress to identify additional actors and use cases that comprise our model of the ATM system. Figure 4.4, “Use case diagram for an ATM system showing include relationships.” and Figure 4.5, “Use case diagram for an ATM system showing an extend relationship.” exemplified the essential concepts and components of a use case diagram such as, use cases, actors, multiplicity, and include / extend relationships. They showed the relationships between the actors and use cases, and demonstrated how these actors and use cases interact.
In Figure 4.4, “Use case diagram for an ATM system showing include relationships.” we see a use case diagram for an ATM system consisting of «include» relationships for the use cases, Maintain ATM and Use ATM. Maintain ATM was further defined by two use cases, "Maintain Equipment" and "Reload ATM". Use ATM was further defined in terms of the behavior of three simpler use cases: "Deposit Cash", "Withdraw Cash" and "Query Account".

Use Case Diagrams

Diagrams
Purpose - To present the diagrams to the user and allow the user to manipulate the diagrams through the view.
The Diagrams are located in org.argouml.uml.diagram.
The Diagrams are a View subsystem. Section 4.5, “View and Control subsystems”.
The Diagrams depend on the Model subsystem and the GUI.
The classes in this subsystem are extensions of the GEF base classes (GraphModels, Figs, Selections etc) together with some supporting classes.
This subsystem has no direct access to a specific implementation of the OMG model repository. However it does update such a repository via the interface of the Model Subsystem.
There is an intention (Bob Tarling) to split this subsystem into several smaller subsystems, one for each diagram type. This is to allow for indiviual diagram reuse by other applications and to allow us to fast track developers onto a specific subproject containing that subsystem (Michael MacDonald and sequence diagrams in mind).
5.3.1. Multi editor pane
The multi editor pane is the pane with the diagram editor in it. Normally it is placed in the upper right corner of the application. One of the feature requests is to make the pane dockable so maybe it won't be there in the future.
The multi editor pane consists of tabs that hold editors as you can see in the class diagram.

At the moment there is only one editor tab in place. This is the TabDiagram that shows an UMLDiagram, the target.
The TabDiagram is spawn-able. This means that the user can double click the tab and the diagram will spawn as a separate window.
The target of the MultiEditorPane is set via the setTarget method of the pane. This method is called by the setTarget method of the ProjectBrowser. The pane's setTarget method will call each setTarget method of each tab that is an instance of TabModelTarget. Besides setting the target of the tabs, the setTarget method also calls MultiEditorPane.select(Object o). This selects the new target on a tab. This probably belongs in the setTarget method of the individual tabs and diagrams but that's how it's implemented at the moment.
5.3.1.1. How do I ...?

...add a new tab to the MultiEditorPane?
Create a new class that's a child of JPanel and put the following line in argo.ini: multi: fully classified name of new tab class


5.3.2. How do I add a new element to a diagram?
To add a new element to a diagram, two main things have to be done.
Create new Fig classes to represent the element on the diagram and add them to the graph model (org.argouml.uml.diagram.xxxx.XxxxDiagramGraphModel.java) and renderer (org.argouml.uml.diagram.xxxx.ui.XxxxDiagramRenderer.java).
Create a new property panel class that will be displayed in the property tab window on the details pane. This is described in Section 5.4, “Property panels”.
Throughout we shall use the example of adding the UML Extend relationship to a use case diagram. This allows two Use Cases to be joined by a dotted arrow labeled «extend» to show that one extends the behavior of the other.
The classes involved in this particular example have all been well commented and have full Javadoc descriptions, to help when examining the code. You will need to read the description here in conjunction with looking at the code.
5.3.3. How to add a new Fig
The new item must be added to the tool-bar. Both the graph model and diagram renderer for the diagram will need modifying for any new fig object.
5.3.3.1. Adding to the tool-bar of the diagram
Find the diagram object in uml/diagram/XXXX/ui/UMLYYYYDiagram.java, where XXXX is the diagram type (lower case) and YYYY the diagram type (bumpy caps). For example uml/diagram/use_case/ui/UMLUseCaseDiagram.java. This will be a subclass of UMLDiagram (in uml/diagram/ui/UMLDiagram.java).
Each tool-bar action is declared as a private static field of class Action, initiated as a new CmdCreateNode (for nodal UML elements) or a new CmdSetMode (for behavior, or creation of line UML elements). These classes are part of the GEF library.
The common ones (select, broom, graphic annotations) are inherited from UMLDiagram, the diagram specific ones in the class itself. For example in UMLUseCaseDiagram.java we have the following for creating Use Case nodes. private static Action actionUseCase;
which is then created as follows: protected Action getActionUseCase() {
if (actionUseCase == null) {
actionUseCase = new RadioAction(new CmdCreateNode(
Model.getMetaTypes().getUseCase(), "button.new-usecase"));
}
return actionUseCase;
}

The first argument of the CmdCreateNode() function is the class of the node to create from the Model subsystem Metatypes interface, the second a textual tool tip.
The tool-bar is actually created by defining a method, UMLDiagram.initToolBar() which adds the tools in turn to the tool-bar (a private member named toolBar).
The default constructor for the diagram is declared public, despite that it must not be called directly - it is needed for loading projects from files. The desired constructor takes a name-space as an argument, and sets up a graph model (UseCaseDiagramGraphModel), layer perspective and renderer (UseCaseDigramRenderer) for nodes and edges.
5.3.3.2. Changing the graph model
The graph model is the bridge between the UML meta-model representation of the design and the graph model of GEF. They are found in the parent directory of the corresponding diagram class, and have the general name YYYYDiagramGraphModel.java, where YYYY is the diagram name in bumpy caps. For example the use case diagram graph model is in uml/diagram/use_case/UseCaseDiagramGraphModel.java
The graph model is defined as UMLMutableGraphSupport, a child of the GEF class MutableGraphSupport, and should implement MutableGraphModel (GEF).
5.3.3.3. Changing the renderer
The renderer is responsible for creating graphic figs as required on the diagram. It is found in the same directory of the corresponding diagram class, and has the general name YYYYDiagramRenderer.java, where YYYY is the diagram name in bumpy caps. For example the use case diagram graph model is in uml/diagram/use_case/ui/UseCaseDiagramRenderer.java
This provides two routines, getFigNodeFor(), which provides a fig object to represent a given UML node object and getFigEdgeFor(), which provides a fig object to represent a given UML edge object.
In our example, we must extend getFigEdgeFor() so it can handle UML Extend objects (producing a FigExtend).
5.3.3.4. Creating a new Fig (explanation 1)
New objects that are to appear on a diagram will require new Fig classes to represent them. In our example we have created FigExtend. They are placed in the same directory as the diagram that uses them.
The implementation of a Fig must provide constructors for both a generic fig, (i.e. without setting the owner - which is used for loading from files) and one representing a specific Model subsystem object. It should provide a setFig() method to set a particular figure as the representation. It should provide a method canEdit() to indicate whether the Fig can be edited. It should provide an event handler modelChanged() to cope with advice that the UML model has changed.
5.3.3.5. Creating a new Fig (explanation 2)
Assuming you have your model element already defined in the model and your PropPanel for that model element you should make the Fig class.
Nodes that are Figs that are enclosed figures like FigClass, extend from FigNodeModelElement. Edges that are lines like FigAssociation, extend from FigEdgeModelElement. The name of the Fig has to start with (yes indeed) Fig. The rest of the name should be equal to the model element name.
Create a default constructor in the Fig. In this default constructor the drawing of the actual figure is done. Here you draw the lines and text fields. See FigClass and FigAssociation for an example of this.
Create a constructor FigMyModelelement(Object owner). Set the owner in this method by calling setOwner. Make a method setOwner that overrides it's super. Let the method call it's super. Set all attributes of the Fig with data from it's owner in this setOwner method. See setOwner of FigAssociation for an example.
Create an overridden method protected void modelChanged(PropertyChangeEvent e). This method must be called (and is if you implement the fig correctly) if the owner changes. In this method you update the fig if the model is changed. See FigAssociation and FigClass for an example.
If you have text that can be edited, override the method textEditStarted(FigText text) and textEdited(FigText text). This latter method is called AFTER the user edited the text. In this method the edited text is parsed. If the parsing is simple and not Notation specific, just do it in textEdited. But for most cases: use the Notation subsystem.
Make an Action that can be called from the GUI. If you are lucky, you just can use CmdCreateNode. See for examples UMLClassDiagram of using CmdCreateNode.
Adapt the method canAddEdge(Object o) on subclasses of GraphModel if you are building an edge so it will return true if the edge may be added to the subclass. Subclasses are for example ClassDiagramGraphModel and UseCaseDiagramGraphModel. If you are building a node, adapt canAddNode(Object o).
Adapt the method getFigEdgeFor on implementors of GraphEdgeRenderer if you are implementing an edge so it will return the correct FigEdge for your object. If you are implementing a node, adapt the method getFigNodeFor on implementors of GraphNodeRenderer. In ArgoUML classes like ClassDiagramRenderer implement these interfaces.
Add an image file for the buttons to the resource directory org/argouml/Images. This image file must be of GIF format and have a drawing of the button image to be used in itself. This image is also used on the PropPanel. The name of the Image file should be model element.gif
Add buttons to the action you created on those places in the GUI that have a need for it. This should be at least the button bar in each diagram where you can draw your model element. Probably the parent of your model element (e.g. class in case of operation) will want a button too, so add it to the PropPanel of the parent. In case of the diagrams, add it in UMLdiagram.java, so in UMLClassDiagram if it belongs there. In case of the PropPanels, use UndoableAction.

Argo UML case Diagrams - Bank System

Output of the Requirements Capture Process
Almost all the output of the requirements capture process is documentary. The only diagram is the use case diagram, showing the relationships between use cases and actors.
4.3.1. Vision Document
Typical sections of this document would be as follows.
Summary. A statement of the context, problem and solution goals.

Goals. What are we trying to achieve (and how do we wish to achieve it).

Market Context or Contractual Arrangements. For a market led development, this should indicate target markets, competitive differentiators, compelling events and so forth. For a contractual development this should explain the key contractual drivers.

Stakeholders. The users (in the widest sense) of the system. Many of these will map in to actors, or control equipment that maps into actors.

Key Features. At the very highest level what are they key functional aspects of the problem/desired solution. These will largely map down to the use cases. It is helpful to give some prioritization here.

Constraints. A high level view of the non-functional parameters of the system. These will be worked out in detail in the supplementary requirements specification.
Appendix. A listing of the actors and use cases that will be needed to meet this vision. It is useful to link to these from the earlier sections to ensure comprehensive coverage.
4.3.2. Use Case Diagram
The vision document has identified the use cases and actors. The use case diagram captures how they interact. In our ATM example we have identified “customer uses machine”, “maintain machine” and “audit” as the three main use cases. We have identified “customer”, maintenance engineer“,”“local branch official” and “central computer” as the actors.
Figure 4.1, “Basic use case diagram for an ATM system” shows how this could be displayed on a use case diagram. The use cases are shown as ovals, the actors as stick people (even where they are machines), with lines (known as associations connecting use cases to the actors who are involved with them. A box around the use cases emphasizes the boundary between the system (defined by the use cases) and the actors who are external.
Note
Not all analysts like to use a box around the use cases. It is a matter of personal choice.

Figure 4.1. Basic use case diagram for an ATM system
The following sections show how the basic use case diagram can be extended to show additional information about the system being designed.
4.3.2.1. Active and Passive Actors
Active actors initiate interaction with the system. This can be shown by placing an arrow on the association from the actor pointing toward the use case. In the ATM example, the customer is an active actor.
Interaction with passive actors is initiated by the system. This can be shown by placing an arrow on the association from the use case pointing toward the actor. In the ATM example, the central computer is a passive actor.
This is a good example where the arrow helps, since it allows us to distinguish an event driven system (the ATM initiates interaction with the central computer) from a polling system (the central computer interrogates the ATM from time to time).
Where an actor may be either active or passive, depending on circumstances, the arrow may be omitted. In the ATM example the bank engineer fits into this category. Normally he is active, turning up on a regular cycle to service the machine. However if the ATM detects a fault, it may summon the engineer to fix it.
The use of arrows on associations is referred to as the navigation of the association. We shall see this used elsewhere in UML later on. The choice, by the OMG, of zero vice two arrowheads to show a bidirectional association is unfortunate. Under this convention you cannot distinguish between an association whose navigation has yet to be determined and one that is bidirectional.
Figure 4.2, “Use case diagram for an ATM system showing navigation.” shows the ATM use case diagram with navigation displayed.

Figure 4.2. Use case diagram for an ATM system showing navigation.
4.3.2.2. Multiplicity
It can be useful to show the multiplicity of associations between actors and use cases. By this we mean how many instances of an actor interact with how many instances of the use case.
By default we assume one instance of an actor interacts with one instance of a use case. In other cases we can label the multiplicity of one end of the association, either with a number to indicate how many instances are involved, or with a range separated by two periods (..). An asterisk ( *) is used to indicate an arbitrary number.
In the ATM example, there is only one central computer, but it may be auditing any number of ATM uses. So we place the label 0..* at the use case end. There is no need for a label at the other end, since the default is one.
A local bank will have up to three officials authorized to unload and load ATM machines. So at the actor end of the relationship with the use case Maintain ATM, we place the label 1..3. They may be dealing with any number of ATM machines, so at the other end we place the label 0..*.
There may be any number of customers and there may be any number of ATM systems they could use. So at each end of the association we place the label 0..*.
Figure 4.3, “Use case diagram for an ATM system showing multiplicity.” shows the ATM use case diagram with multiplicity displayed.

Figure 4.3. Use case diagram for an ATM system showing multiplicity.
Multiplicity can clutter a diagram, and is often not shown, except where it is critical to understanding. In the ATM example we would only choose to show 1..3 against the local bank official, since all others are obvious from the context.
4.3.2.3. Hierarchies of Use Cases
In our ATM example so far we have just three use cases to describe all the behavior of the system. While use cases should always describe a significant chunk of system behavior, if they are too general they can be difficult to describe.
We could for example define the behavior of the use case “Use ATM” in terms of the behavior of three simpler use cases, “Deposit Cash”, “Withdraw Cash” and “Query Account”. The main use case could be specified by including the behavior of the subsidiary use cases where needed.
Similarly the “Maintain ATM” use case could be defined in terms of two use cases “Maintain Equipment” and “Reload ATM”. In this case the two actors involved in the main use case are really only involved in one or other of the two subsidiary use cases and this can be shown on the diagram.
The decomposition of a use case into simpler sub-use cases is shown in UML by using an include relationship, a dotted arrow from the main use case to the subsidiary, with the label «include».

Figure 4.4. Use case diagram for an ATM system showing include relationships.
Include relationships are fine for breaking down the use case behaviors in to hierarchies. However we may also want to show a use case that is an extension to an existing use case to cater for a particular circumstance.
In the ATM example we have a use case covering routine maintenance of the ATM, “Maintain Equipment”. We also want to cover the special case of an unscheduled repair caused by the ATM detecting an internal fault.
This is shown in UML by the extend relationship. In the main use case, we specify a name for a location in the description, where an extension to the behavior could be attached. The name and location are shown in a separate compartment within the use case oval. The representation extend relationship is the same as the include relationship, but with the label «extend». Alongside the extend relationship, we specify the condition under which that behavior will be attached.
Figure 4.5, “Use case diagram for an ATM system showing an extend relationship.” shows the ATM use case diagram with an extend relationship to a use case for unscheduled repairs. The diagram is now getting rather complex, and so we have split it into two, one for the maintenance side of things, the other for customer usage and audit.
The “Maintain Equipment” use case defines a name “Unsched”, at the start of its description. The extending use case “Unscheduled Repair” is attached there when the ATM detects an internal error.

Figure 4.5. Use case diagram for an ATM system showing an extend relationship.

Use cases may be linked together in one other way. One use case may be a generalization of a subsidiary use case (or alternatively the subsidiary is a specialization of the main use case). This is very like the extends relationship, but without the constraint of specific extension points at which the main use case may be extended, and with no condition on when the subsidiary use case may be used.
Generalization is shown on a use case diagram by an arrow with solid line and solid white head from the subsidiary to the main use case. This may be useful when a subsidiary use case specializes the behavior of the main use case at a large number of positions and under a wide range of circumstances. However the lack of any restriction makes generalization very hard to specify precisely. In general use an extend relationship instead.
4.3.3. The Use Case Specification
Each use case must be documented to explain in detail the behavior it is specifying. ArgoUML assists in this area through the generation of graphic files for inclusion in this documentation. This document is known by different names in different processes: use case specification, use case scenario or even (confusingly) just use case.
A typical use case specification will include the following sections.

Name. The name of the use case to which this relates.

Goal. A one or two line summary of what this use case achieves for its actors.
Actors. The actors involved in this use case, and any context regarding their involvement.
Note
This should not be a description of the actor. That should be associated with the actor on the use case diagram.

Pre-condition. These would be better named “pre-assumptions”, but the term used everywhere is pre-conditions. This is a statement of any simplifying assumptions we can make at the start of the use case.
In the ATM example we might make the assumption for the“Maintain Equipment” use case that an engineer is always available, and we do not need to worry about the case where a routine maintenance visit is missed.
Caution
Avoid pre-conditions wherever possible. You need to be absolutely certain that the pre-condition holds under all possible circumstances. If not your system will be under specified and hence will fail when the pre-condition is not true. Alternatively, when you cannot be certain the pre-condition is always true, you will need to specify a second use case to handle the pre-condition being false. In the first case, pre-conditions are a source of problems, in the second a source of more work.

Basic Flow. The linear sequence of steps that describe the behavior of the use case in the “normal” scenario. Where a use case has a number of scenarios that could be normal, one is arbitrarily selected. Specifying the basic flow is described in more detail in Section 4.3.3.1, “Specifying the Basic Flow” below.

Alternate Flows. A series of linear sequences describing each of the alternative behaviors to the basic flow. Specifying alternate flows is described in more detail in Section 4.3.3.2, “Specifying the Alternate Flows”.

Post-conditions. These would be better named “post-assumptions”. This is a statement of any assumptions that we can make at the end of the use case. Most useful where the use case is one of a series of subsidiary use cases that are included in a main use case, where they can form the pre-conditions of the next use case to be included.
Caution
Like pre-conditions, post-conditions are best avoided. They place a burden on the specification of the use case flows, to ensure that the post-condition always holds. They therefore are also a source of problems and extra work.
Requirements. In an ideal world the vision document, use case diagrams, use case specifications and supplementary requirements specification would form the requirements for a project.
For most market-led developments, where ownership of requirements is within the same business as the team who will do the development, this is now usually the case. The marketing department can learn use case based requirements capture and analysis to link to their customer facing activities.
However for external contract developments, customers may insist on a traditional “list of features” as the basis of the contract. Where this is the case, this section of the use case specification should link to the contract features that are covered by the use case.
This is often done through a third party tool that can link documents, providing automated checking of coverage, in which case this section is not needed, or may be generated automatically.
The final size of the use case specification will depend on the complexity of the use case. As a rule of thumb, most use cases take around 10-15 pages to specify, the bulk of which is alternate flows. If you are much larger than this, consider breaking the use case down. If you are much smaller consider whether the use case is addressing too small a chunk of behavior.
4.3.3.1. Specifying the Basic Flow
All flows in a use case specification are linear—that is there is no conditional branching. Any choices in flows are handled by specifying another alternate flow that takes over at the choice point. It is important to remember we are specifying behavior here, not programming it.
A flow is specified as a series of numbered steps. Each step must involve some interaction with an actor, or at least generate a change that is observable externally by an actor. Requirements capture should not be specifying hidden internal behavior of a system.
For example we might give the following sequence of steps for the basic flow of the use case "Withdraw Cash" in our ATM example.
Customer indicates a receipt is required.
Customer enters amount of cash required.
ATM verifies with the central computer that the customer can make this withdrawal.
ATM dispenses cash to the customer.
ATM issues receipt to customer.
Remember this is a sub-use case included in the main “Use ATM” use case, which will presumably handle checking of cards and PINs before invoking this included use case.
Note
The first step is not a condition. We take as our basic flow the case where the customer does want a receipt. The case where the customer does not want a receipt will be an alternative flow.
4.3.3.2. Specifying the Alternate Flows
This captures the alternative scenarios, as linear flows, by reference to the basic flow. Initially we just build a list of the alternate flows.
Customer does not require a receipt.
Customer's account will not support the withdrawal.
Communication to the central computer is down.
The customer cancels the transaction.
The customer fails to take the dispensed cash.
Subsequently we flesh out each alternate flow, by reference to the basic flow. For example the first alternate flow might look like.
Customer does not require a receipt.
At step 1 of the basic flow the customer indicates they do not want a receipt.
The basic flow proceeds from step 2 to step 4, and step 5 is not used.
The convention is to number the various alternate flows as A.1, A.2, A.3, etc. The steps within an alternate flow are then numbered from this. So the steps of the first alternate flow would be A.1.1, A.1.2, A.1.3, etc.
4.3.3.3. Iterative Development of Use Case Specifications
Iterative development will prioritize the use cases, and the first iterations will address the most important.
Early iterations will capture the basic flows of the most important use cases with only essential detail and list the headings of the main alternate flows.
Later iterations will address the remaining use cases, flesh out the steps on individual alternate flows and possibly provide more detail on individual steps.
4.3.4. Supplementary Requirement Specification
This captures the non-functional requirements or constraints placed on the system. Since use cases are inherently functional in nature, they cannot capture this sort of information.
Note
Some analysts like to place non-functional requirements in a section at the end of each use case specification, containing the non-functional requirements relevant to the use case.
This can cause some problems. First key non-functional requirements (for example about performance) may need to appear in many use cases and it is bad practice to replicate information. Secondly there are invariably some non-functional requirements that are system wide and need a system wide document. Hence my preference for a single supplementary requirements specification.
There should be a section for each of the main areas of non-functional requirements. The checklist provided by Ian Sommerville in his book Software Engineering (Third Edn, Addison-Wesley, 1989) is a useful guide.
Speed. Processor performance, user/event response times, screen refresh time.
Size. Main memory (and possibly caches), disc capacity.
Ease of use. Training time, style and detail of help system.
Reliability. Mean time to failure, probability of unavailability, rate of failure, availability.
Robustness. Time to restart after failure, percentage of events causing failure, probability of data corruption on failure.
Portability. Percentage of target-dependent code/classes, number of target systems.
To this we should add sections on environment (temperature, humidity, lightening protection status) and standards compliance.