Use cases sound similar to test cases. But the two are not same. Where the test cases are used in software testing, the use cases are used in the general software systems engineering. We have dedicated this whole article to the discussion of the use cases.
What are Use Cases?
- The use case is a set of steps which are implemented to define the interactions occurring between the software system and a role.
- This is basically done to achieve a predefined goal. The role is commonly called as an actor and can be an external software system or simply a human.
- The use cases are often used at the higher levels of the software systems engineering.
- The goals to achieve for which the use cases are developed are often defined by the stake holders.
- The requirements are stated by the stake holders in a separate documentation.
- This documentation serves at a contract between the two i.e., between the software developers or programmers and the stake holders or the clients.
- The structure of a use case has been a quite debated topic. Many opinions were given regarding the how the structure of a typical use case should be.
- But usually the structure defined by the Alistair Cockburn is followed. It is popularly known as the “fully dressed use case structure”.
It consists of the following aspects:
1. Title of the use case
2. Primary role
3. Goal of the use case
4. Scope
5. Level
6. Interests
7. Stake holders
8. Preconditions or requirements
9. Guarantees (both minimal and success)
10.Success scenario
11. Technology
12. Data variations
13. Extensions and
14. Related information
He gave some other many useful aspects related to the use cases like:
1. Casual use case structure
2. Design scope icon
3. Goal level icon
ROLE OF AN ACTOR
- The role of an actor in a use case is to make effective decisions and so calls for the need of good decision making ability.
- It is not necessary that an actor should always be a human. It can be a computer system also.
- Though the decisions of an actor influences the whole use case implementation, there does not exist any direct link between the system and the actor.
ATTRIBUTES OF USE CASES
- Certain necessary attributes have been discovered so far that are needed by the use case to accomplish the goal for which it has been developed.
- The attributes need not be only functions; they can be in the form of data variables also.
- Not all the attributes have been extracted from the preceding steps; some have been taken as the general assumptions out of common knowledge of the use cases.
1. System requirements: These requirements form the basis for thedelopmnt of a use case.
2. The requirements need to be complete and correct and of quality.
3. Software requirements specification testing
4. User- centred approach for the specification of the requirements.
5. Unified modelling language: this language based on the object oriented paradigm is employed for the construction, visualization and documentation of the system.
6. Use case diagrams
The below mentioned are the three attributes of the use cases:
1. Level of validity
This attribute is concerned with the validation of the use cases. It queries about the completeness of the use case, achievement of the goals, changes to be made, addressing of the additional goals and representation of the additional actors and so on.
2. Metrics
This use case attribute deals with the factors like the ambiguity, completeness, trace-ability and volatility of the use case.
3. Risk indicators
Typical 3 risk indicators have been identified namely incompleteness, options and weak phrases.
Tuesday, March 6, 2012
What are the different attributes of the use cases?
Posted by
Sunflower
at
3/06/2012 11:30:00 PM
0
comments
Labels: Actor, Application, Attributes, Complete, Correctness, Data, Decision, Design, Errors, Goals, Implementation, Quality, Requirements, Software Systems, Software testing, Structure, Use cases
|
| Subscribe by Email |
|
Friday, May 6, 2011
What makes a good Software Test Engineer, SQA Engineer, Test Manager?
A good software test engineer has the following qualities:
- a software engineer should focus on having a high quality product.
- a software engineer should understand customer's needs and requirements.
- a software engineer should maintain a tactful and diplomatic relationship with developers.
- a software engineer should maintain a good relationship with non technical people.
- a software engineer should be able to have a judgment skill when needed.
A good Software Quality Assurance engineer has the following qualities:
- a software quality assurance engineer should focus on having a high quality product.
- a software quality assurance engineer should understand customer's needs and requirements.
- a software quality assurance engineer should maintain a tactful and diplomatic relationship with developers.
- a software quality assurance engineer should maintain a good relationship with non technical people.
- a software quality assurance engineer should be able to have a judgment skill when needed.
- a software quality assurance engineer should have a proper understanding of software development life cycle.
- a software quality assurance engineer should understand business approach and goals.
- a software quality assurance engineer should have good communications skills.
- a software quality assurance engineer should be able to find problem areas.
A good QA/Test Manager has the following properties
- he should have a good understanding of software development life cycle.
- he should have a good and healthy relation with the technical and non technical people.
- he should be able to increase his team's productivity and efficiency.
- he should be able to create enthusiasm about work among team members.
- he should be able to make correct and quick decisions.
- he should be good at handling pressure.
- he should have diplomatic skills.
Posted by
Sunflower
at
5/06/2011 03:33:00 PM
1 comments
Labels: Approach, Correctness, Decision, Efficiency, Problems, Quality, Requirements, SDLC, Skills, Software quality assurance, Software testing, SQA engineer, Test Manager, Text Engineer
|
| Subscribe by Email |
|
Thursday, March 3, 2011
How do we create an architectural design....an overview
Design is an activity concerned with making major decisions, often of a structural nature. It is a multi-step process in which representations of data and program structure, interface characteristics, and procedural detail are synthesized from information requirements.
Architectural design represents the structure of data and program components that are required to build a computer based system. It considers the architectural style that the system will take, the structure and properties of the components that constitute the system, and the interrelationships that occur among all architectural components of a system. A software engineer can design both data and architecture, the job is often allocated to specialists when large, complex systems are to be built. A database or data warehouse designer creates the data architecture for a system. The system architect selects an appropriate architectural style for the requirements derived during system engineering and software requirements analysis.
Architectural design provides with the big picture and ensures that you have got it right in a same manner as before building a house, you need a blueprint. Architectural design begins with data design and then proceeds to the derivation of one one or more representations of the architectural structure of the system. Alternative architectural styles or patterns are analyzed to derive the structure that is best suited to customer requirements and quality attributes. Once an alternative has been selected, the architecture is elaborated using an architectural design method.
An architecture model encompassing data architecture and program structure is created during architectural design. In addition, component properties and relationships are also described. At each stage, software design work products are reviewed for clarity, correctness, completeness, and consistency with requirements and with one another.
Posted by
Sunflower
at
3/03/2011 08:21:00 PM
0
comments
Labels: Architectural design, Architecture, Completeness, Components, Correctness, Design, Design models, Models, Patterns, Process Requirements, Representation, Steps, Structure, Work Products
|
| Subscribe by Email |
|