Joseph Butson

Process: OOAD

Use Cases

This page is the search results from IBM’s Rational Developer works and so there are some good things to review. It might be too much. But it might also worth bookmarking too.

If you would like to listen to an excellent Use Case lecture from a plain speaking Use Case pro, visit this presentation. You will need to set aside some time to listen but I think this one of the best discussions I have read or heard.
Design Patterns

Visit this page for the Gang of Four’s work in design patterns.
You download a best practice glossary here. Or just browse it below.

The Zachman Framework isn’t specific to OOAD but it is still a useful body of work to consider.

Glossary

Actor

Someone or something, outside the system that interacts with the system.

Artifact

A piece of information that is used or produced by a software development process. An artifact can be a model, a description, or software. Synonym: product.

Baseline

A reviewed and approved release of artifacts that constitutes an agreed basis for further evolution or development and that can be changed only through a formal procedure, such as change management and configuration control .

Customer

A person or organization, internal or external to the producing organization, who takes financial responsibility for the system. In a large system this may not be the end user. The customer is the ultimate recipient of the developed product and its artifacts. See also stakeholder.

Change Control Board (CCB)

The role of the CCB is to provide a central control mechanism to ensure that every change request is properly considered, authorized and coordinated.

Change Management

The activity of controlling and tracking changes to artifacts. See also scope management.

Change Request (CR)

A general term for any request from a stakeholder to change an artifact or process. Documented in the Change Request is information on the origin and impact of the current problem, the proposed solution, and its cost. See also enhancement request, defect.

Configuration Manager

The configuration manager is responsbile for setting up the product structure in the Change Management system, for defining and allocating workspaces for developers, and for integration. The configuration manager also extracts the appropriate status and metrics reports for the project manager .

Defect

An anomaly, or flaw, in a delivered work product. Examples include such things as omissions and imperfections found during early lifecycle phases and symptoms of faults contained in software sufficiently mature for test or operation. A defect can be any kind of issue you want tracked and resolved. See also change request.

Developer

A person responsible for developing the required functionality in accordance with project-adopted standards and procedures. This can include performing activities in any of the requirements, analysis & design, implementation, and test disciplines.

Document

A document is a collection of information that is intended to be represented on paper, or in a medium using a paper metaphor. The paper metaphor includes the concept of pages, and it has either an implicit or explicit sequence of contents. The information is in text or two-dimensional pictures. Examples of paper metaphors are word processor documents, spreadsheets, schedules, Gantt charts, web-pages, or overhead slide presentations.

Enhancement Request

A type of stakeholder request that specifies a new feature or functionality of the system. See also change request.

Feature

An externally observable service provided by the system which directly fulfills a stakeholder need.

I/T

Information Technology

Iteration

A distinct sequence of activities with a base-lined plan and valuation criteria resulting in a release (internal or external).

Quality Assurance (QA)

The function of Quality Assurance is the responsibility of (reports to) the Project Manager and is responsible for ensuring that project standards are correctly and verifiably followed by all project staff.

Project Manager

The role with overall responsibility for the project. The Project Manager needs to ensure tasks are scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements.

Requirement

A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document. A desired feature, property, or behavior of a system.

Requirement Attribute

Information associated with a particular requirement providing a link between the requirement and other project elements—for example, priorities, schedules, status, design elements, resources, costs, hazards.

Requirement Type

A categorization of requirements—for example, stakeholder need, feature, use case, supplementary requirement, test requirement, documentation requirement, hardware requirement, software requirement, and so on—based on common characteristics and attributes.

Requirements Management

A systematic approach to eliciting, organizing and documenting the requirements of the system, and establishing and maintaining agreement between the customer and the project team on the changing requirements of the system.

Requirements Specifier

The requirements specifier details the specification of a part of the system’s functionality by describing the requirements aspect of one or several use cases and other supporting software requirements. The requirements specifier may also be responsible for a use-case package, and maintains the integrity of that package. It is recommended that the requirements specifier responsible for a use-case package is also responsible for its contained use cases and actors.

Requirements Tracing

The linking of a requirement to other requirements and to other associated project elements.

Role

A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization.

Scope Management

The process of prioritizing and determining the set of requirements that can be implemented in a particular release cycle, based on the resources and time available. This process continues throughout the lifecycle of the project as changes occur. See also change management.

Stakeholder

An individual who is materially affected by the outcome of the system.

Stakeholder Need

The business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use.

Stakeholder Request

A request of any type—for example, Change Request, enhancement request, request for a requirement change, defect—from a stakeholder.

Software Requirement

A specification of an externally observable behavior of the system; for example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment .

Team Leader

The team leader is the interface between project management and developers. The team leader is responsible for ensuring that a task is allocated and monitored to completion. The team leader is responsible for ensuring that development staff follow project standards, and adhere to project schedules.

Traceability

The ability to trace a project element to other related project elements, especially those related to requirements. Project elements involved in traceability are called traceability items.

Use Case (class)

A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A use case contains all alternate flows of events related to producing the “observable result of value”.
More formally, a use case defines a set of use-case instances or scenarios.

User

A person who will use the system that is developed.

Vision (document)

The user’s or customer’s view of the product to be developed, specified at the level of key stakeholder needs and features of the system