I have newly changed my company on manual testing role and my manager asked me to make trace-ability matrix for the requirements or test cases (I am not sure). However, this is the first time I am hearing about this word 'trace-ability matrix'. However, on some blogs based on the info provided, I understood it is similar like writing business scenario, test scenario and test cases. Is my understanding correct.?
What is a Traceability Matrix?
It is used to track the requirements and to check the current project requirements are met. That is, a traceability matrix is a document that co-relates any two-baseline documents that require a many-to-many relationship to check the completeness of the relationship.
Requirement Trace-ability Matrix
Requirement Trace-ability Matrix or RTM captures all requirements proposed by the client or development team and their trace-ability in a single document delivered at the conclusion of the life-cycle.
In simple words, it is a document that maps and traces user requirement with test cases. The main purpose of Requirement Traceability Matrix is to see that all test cases are covered so that no functionality should miss while testing.
RTM Parameter includes:
Requirement ID
Risks
Requirement Type and Description
Trace to design specification
Unit test cases
Integration test cases
System test cases
User acceptance test cases
Trace to test script
There are three types of Traceability Matrix as per my knowledge
Forward traceability
Backward or reverse traceability
Bi-directional traceability ( Forward+Backward)
Forward traceability: This matrix is used to check whether the project progresses in the desired direction and for the right product. It makes sure that each requirement is applied to the product and that each requirement is tested thoroughly. It maps requirements to test cases.
Backward or reverse traceability: It is used to ensure whether the current product remains on the right track. The purpose behind this type of traceability is to verify that we are not expanding the scope of the project by adding code, design elements, test or other work that is not specified in the requirements. It maps test cases to requirements.
Bi-directional traceability ( Forward+Backward): This traceability metrics ensures that all requirements are covered by test cases. It analyzes the impact of a change in requirements affected by the defect in a work product and vice versa.
Advantage of Requirement Traceability Matrix
It confirms 100% test coverage
It highlights any requirements missing or document inconsistencies
It shows the overall defects or execution status with a focus on business requirements
It helps in analyzing or estimating the impact on the QA team's work with respect to revisiting or re-working on the test cases
The traceability matrix is a common and really useful tool for the testing procedures. Thanks to the matrix results it is possible to obtain some very important coverage metrics related to the test procedures. You have to fix two metrics as table inputs (e.g. x values and y values) and to insert a cross in the cells where the relationship between the two inputs is satisfied. In particular, some common traceability matrix are:
test cases <--> requirements: this kind of matrix helps the testers to estimate the coverage of the realized test cases for the given results. Empty cells in this table means that more test cases have to be produced to cover all the given requirements,
requirements <--> source code: this matrix helps to understand if some produced code is not covered by any requirement. An empty cell can be caused by the insufficient requirements number or by code that is superfluous,
test cases <--> source code: this matrix is useful to understand what is the percentage of the tested code. More than one reason can cause an empty cell.
"A requirements traceability matrix (RTM) is a simple and effective tool that allows to establish and maintain bidirectional traceability for your project.
As the name suggests a RTM is nothing more than a table that displays the relation between different development artifacts. Due to its simplicity it can be created with the most basic tool – for example with excel. It sometimes even makes sense to draw it on a white board to make it visible to everyone on the team. Depending on the purpose you are creating the RTM for, it can visualize direct links between ‘linked’ artifacts, shows cumulated views on entire ‘traces’."
[https://blogs.itemis.com/en/how-to-create-a-requirements-traceability-matrix]
Related
Little background
I'm new to writing use cases and representing their scenarios.
I'm dealing with a complex system. In the first step of analyzing the system, I created a use case diagram where each use case represents a distinct goal or value for the system. I have tried my best to keep the use cases independent. All these use cases require the initialization and activation of the system, so I decided to take out this common part and link it to the main use cases using include relationship.
I understand that include and extend relationships need to be used only when necessary.
Now I'm lookin into defining scenarios for each use case and then developing user stories and requirements based on scenarios.
Main issue
The use cases are very complex and the easiest way to analyze it seems to be mapping it into a sequence of steps/activities where each activity contains several scenarios and each scenario is represented using a sequence diagram.
I understand that an activity cannot be a use case which is related to the main use case using include relationship; but having sequence diagrams for activities seem wrong too.
What is the best way to represent a use case where each step of the main flow is complex and can have several interactions between actors and systems as well as having error scenarios which can result in termination of the sequence at that step or possibility of the user cancelling/aborting the sequence?
I have attached a simplified version of the activity diagram for "Initialize" use case.
As I mentioned, each activity can have many scenarios. For example
"Perform Self check" has many steps and each step might result in a failure that can terminate the sequence and alert the user (via a HMI). The user then can either terminate the initialization or retry.
"Validate system configuration" include steps for obtaining the reference config versions and comparing that to the system config, then download the new config files if necessary and then update the system configs. Each step might have a failure resulting in some sort of message to user and termination of the sequence. In some cases user should be able to skip the failed steps and proceed without doing that activity.
Same goes for every other activity in the diagram; many steps with exception or alternative paths.
Can I map these on one sequence diagram for the "Initialize" Use case?
My attempt to put all these on one sequence diagram failed.
I tried putting all these interactions on an activity diagram with swimlanes but things got so complex that stakeholders have a hard time understanding what is going on.
Maybe I'm trying to put too much details at the system level. Should I leave all these interim steps and interaction for the lower level of design? Should I create a hierarchy of use cases and roll down the complexity? I'm confused. :(
What is the best way to deal with such level of complexity? Could you provide some good examples.
The only way to represent a complex use case, where every step of the main flow can have multiple scenarios, is fortunately very simple:
The complexity of the scenarios does not change anything to the simplicity of the actor's goals. And if the goals are not sufficiently simple, you'd probably looking at too much details. Or the things are not as clear as they should.
The scenarios are often represented with a set of sequence diagrams. But if it gets really complex you'd better show the flow with an activity diagram.
By the way, you do not need to create an artificial extending or included use-case for the sake of modelling common steps. You may just create a separate activity diagram for the common part. Then, in each of your use-case activity diagram, you'd insert a call action of the common activity. This also avoids to misleadingly include the common part in the description of one UC and forget it for the others.
Last but not least, you also want to develop user-stories based on the use-case scenario. This is a mixed approach that requires some more thoughts:
user-stories are generally used without use-cases. Complex erquirements are described as an epic. The epic would then successfully be refine it into user-stories, that fit in an iteration;
it is possible to structure such user-stories according to stakeholder goals and tasks. THis approach is called user-story mapping. This is closer to the use-case, but there is no term to describe the higher-level goals.
use-case driven development is generally used without user-stories: the scenarios and activity directly lead to development without intermeriate user-stories.
Fortunately, the Use-Case 2.0 approach allows to combine both ways. Read the linked whitebook: it's short, it's free, it's written by the inventor of use-cases together with leading authors of use-case methodology; it offers a reegineered appraoch that allows agile developments, using use-case for the big picture and using use-case slices to break it down dynamically into units that can be developped in one iteration.
A complex use case can remain a single use case, but it may need multiple diagrams to specify its flows.
Your activity diagram (although not 100% UML compliant) gives a good overview of the flow of the use case. Keep this as the main diagram. I would decompose the complex steps in separate diagrams. To indicate that a step is decomposed in a separate diagram, you can display a rake symbol, as follows:
See UML 2.5.1 specification, section 16.3.4.1 for more information.
I need to create an expense tracking tool. This tool will allow an individual user to keep a record of their expenses and also to predict financial status at a certain date.
User Interface
This will be built as a .NET C# windows forms desktop application. You are free to design the user interface as you wish but here are the minimal requirements.
The interface must have at least these views:
A contacts view for entering and updating the details of contacts (payers
or payees).
An expenses entry view for entering and updating expense details for a
certain day.
A financial report view – showing all expenses for a chosen date range.
A view that enables the user to see their predicted financial state at a
certain date.
For extra credit:
A view for entering events: appointments and tasks.
A weekly view displaying daily events and expenses.
It is up to you how you design your forms. We are purposely not giving you a
design example to avoid everyone having the same design. You are advised to
create mockups and storyboards and modify them iteratively as you develop your design document.
Your design decisions should be included in your report.
Persistent storage of run time data
The data for the expenses will be created by a view that allows the
specification of the expenses to be entered for a date, and this should be a programmatic dynamic interface. Once the user has finished you need to save
the expense data as an XML file and in a database of your choice. When the
application is run again (after closing) the system shall use the XML data to
populate the data on your interface. It should use the database data for the
financial report. When writing to or reading from the database the activity
should be threaded (to enable the interface to be useable while writing to an
external database)
My UML diagram
Can you please review the following diagram ?
Are use case suitable for UI requirements ?
A use case represents a goal that an actor wants to achieve. It is a behavior (in general an action). It's not how the user shall achieve the goal; not either the description of the user interface; and even less a data model.
If you have to design a user interface (as the narrative of your exercise seems to require), you might not need UC but rather wireframes to sketch the UI.
What are the UC in your requirements ?
With this in mind, I would identify the following UC in your requirements:
Manage contact details (#1) - I used Maemphasized textnage to shorten Enter or update -Open question: maybe two UC after all: Manage Payer details + Manage payee details.
Manage expenses for a day (#2) - the selection of date is a detail of the UI, not a UC !
Report expenses (#3) - the selection of date range is a detail of the UI, not a UC !
Forecast financial situation (#4)
Enter (maintain?) events (#5)
Report weekly situation (#6)
What can be improved in your diagram ?
Now a review of your own UC diagram:
Select data range could be an include for Add transation and Generate reports (caution: typo), since it is a part of the behavior and the including UC are incomplete without the included UC. Note that having it as a separate UC seems to me artificially detailed and not to be recommended.
Select data range should in principle not be an extension for Add transation, because an extension is optional and the extended UC should be complete without the extension. And here, it makes no sense to Add a transaction without knowing the date.
I'd suggest to change the UC name from to an active behavior: Chose/select data range, Generate/Report weekly view
You currently use generalization in your use case. Although it is not the most common practice, this is perfectly legal: the UC is a classifier and classifiers can be generalized. However, when generalization is used in an UC, it's generally with the same graphical flavour as all the other "links", separate and between only two elements, and usually not in the shared target form (example). Note that the naming of your specializations sound like nouns corresponding to data objects (e.g Payer) rather than behaviors (e.g. Manage payers). Note also that a typo caused Payee to be there twice
Edit: more about generalization in UC
There is some controversy on use of inheritance in UC since its practical meaning is not as intuitive as the other kind of relations.
Inheritance could be useful when there are several variants of the same UC. It's the principle of abstraction. But a UC should give an easy overview without loosing readers in details. So a better practice would be to keep your diagram without showing the specialisations, and have a second diagram dedicated to these details.
But personally (and looking at the comments and other answers, I'm not alone) I recommend not to use it. It makes a simple and easy to understand diagram, in something more complex with different levels of abstraction. In this reagard, it's worth to mention Ivar Jacobson, the inventor of UC:
He didn't use inheritance in his UC before they were included in UML.
He does not either use it in his most recent work on Use Case 2.0, where he promotes the use of use-case slices to cope with variants.
Use verb to name your UCs, income, expense, payee, Data Range and Weekly View are not UC but they correspond mainly to data.
Some UCs are missing, all what a user can ask to the system is not covered
I do not know what is the right UC for DataRange so difficult to check your extend / include but as Thomas Kilian I have a doubt about them
How one could obtain relevant information for the development of the case model. What is the correct approach?
#Ister is right : capture customer's needs correctly is a whole topic and a complex one.
There are some hints which can be provided:
If you get a state of work, this is the first source
If you get a real customer, after the state of work, workshops about his business and his business processes is the a source
If you want to realize a software with competitors, looking to competitors products is a way to find use cases
State of the art of the domain is also a source
Interview with actors of the domain may be a source
If you work in a domain such as transport, army, medical; there are some norms which can be used to define use cases
Doing UI mock up could be a way to define use cases and business processes. Espacially with non "it aware" guys. The UI is done to realize the business processes, so to show ui mock up may help some customers to define their needs.
your own experience
It is related what Methodology you are using. The steps of your methodology prepare your input about Use Case Modeling.
For example in RUP based methodologies, the inputs of Use Case Modeling are:
Capture a Common Vocabulary
Manage Dependencies
Review Requirements
Detail a Use Case
Detail the Software Requirements
Identify Targets of Test
Identify Test Ideas
Identify Test Motivators
Prioritize Use Cases
Architectural Analysis
Assess Viability of Architectural Proof-of-Concept
Use-Case Analysis
Define Test Approach
Structure the Use-Case Model
You can find:
complete guides of Use Case Modeling
inputs of Use Case Modeling
outputs of Use Case Modeling
Examples
and etc.
in this site.
However, it can be different in other Methodologies.
I have a small UML assignment due Monday; it doesn't seem too complicated, and I'm not asking this site to solve it for me -- I'm just asking for clarification over a couple doubts of mine.
I'm just telling parts of the assignment because its content is probably not so relevant.
We're provided a basic use case where the actors "officer" (e.g. police officer) communicates with the actor "correspondent" in order to report an emergency. The use case is expressed in the form:
Use case name: Report emergency
Participating actors: Officer, correspondent
Flow of events: ...
Preconditions: ...
Postconditions: ...
Then we're given three scenarios that "refine" the use case. I say "refine" because they turn it upside-down: they involve team leaders, respondents, incident handling -- nothing that was even mentioned in the flow of events described by the very basic use case given.
On top of these scenarios we're given ten "events" (i.e. they basically chunk the three scenarios into ten easily recognizable sentences). The assignment asks us to make one collaboration diagram for each of these events.
I know that collaboration diagrams describe the behaviour of the system, i.e. how the different parts of the systems interact with each other. So I thought that, even with these "creative" scenarios given, I could make something out of them. But then this part comes:
"Collaboration diagrams should make use of controller, boundary, domain objects and other new fabricated software objects (e.g. data structure components) necessary to completely handle each event."
And then:
"Your assignment will be evaluated in terms of the quality of your design (i.e. modularity: low coupling, high cohesion)"
My questions are:
1) Are scenarios supposed to present so much new information compared to the basic use case?
2) Do I just have to draw ten simple collaboration diagrams? Using which classes?
3) Why are things like low coupling, high cohesion, domain objects, mentioned? What do they have to do with all of this?
1) A scenario is a detailed description of a use case. There can be several scenarios based on constraints. The use case itself just describes the sunny day scenario in a condensed format. The meat is in the scenarios.
2) Classes related to the UC can be extracted when going through the scenario. You will find text parts that tell certain functions need to be performed. Take these classes and place them in the collaboration diagram and connect them with the right message.
3) These are general design rules. Low coupling/high cohesion means good design (and vice versa). The domain objects are those which are in the center of the system and the sum of all use cases will deal with the sum of all domain objects.
I'll admit that I am still quite a newbie with DDD and even more so with CQRS. I also realize that DDD and/or CQRS might not be the right approach to every problem. Nevertheless, I like the principals but have some questions in the context of a current project.
The solution is a simulator that generates performance data based on the current configuration. Administrators can create and modify the specifications for simulations. Testers set some environmental conditions and run the simulator. The results are captured, aggregated and reported.
The solution consists of 3 component areas each with their own use-cases, domain logic and supporting data structure. As a result, a modular designed seems appealing as a way to segregate logic and separate concerns.
The first area would be the administrative aspect which allows users to create and modify the specifications. This would be a CRUD heavy 'module'.
The second area would be for executing the simulations. The domain model would be similar to the first area but optimized for executing the simulation as opposed to providing a convenient model for editing.
The third area is reporting.
From this I believe that I have three Bounding Contexts, yes? I have three clear entry points into the application, three sets of domain logic and three different data models to support the domain logic.
My first instinct is to follow these lines and create three modules (assemblies) that encapsulate the domain layer for each area. Should I also have three separate databases? Maybe more than three to support write versus read?
I gather this may be preferred for CQRS but am not sure how to go about it. It appears to me that CQRS suggests a set of back-end processes that move data around. But if that's the case, and data persistence is cross-cutting (as DDD suggests), then doesn't my data access code need awareness of all of the domain objects? If so, then is there a benefit to having separate modules?
Finally, something I failed to mention earlier is that specifications are considered 'drafts' until published, which makes then available for simulation. My PublishingService needs to have knowledge of the domain model for both the first and second areas so that when it responds to the SpecificationPublishedEvent, it can read the specification, translate the model and persist it for execution. This makes me think I don't have three bounding contexts after all. Or am I missing something in my analysis?
You may have a modular UI for this, but I don't see three separate domains in what you are describing necessarily.
First off, in CQRS reporting is not directly a domain model concern, it is a facet of the separated Read Model which takes on the responsibility of presenting the domain state optimized for reporting.
Second just because you have different things happening in the domain is not necessarily a reason to bound them away from each other. I'd take a read through the blue DDD book to get a bit better feel for what BCs look like.
I don't really understand your domain well enough but I'll try to give some general suggestions.
Start with where you talked about your PublishingService. I see a Specification aggregate root which takes a few commands that probably look like CreateNewSpecification, UpdateSpecification and PublishSpecification.
The events look similar and probably feel redundant: SpecificationCreated, SpecificationUpdated, SpecificationPublished. Which kind of sucks but a CRUD heavy model doesn't have very interesting behaviors. I'd also suggest finding an automated way to deal with model/schema changes on this aggregate which will be tedious if you don't use code generation, or handle the changes in a dynamic *emphasized text*way that doesn't require you to build new events each time.
Also you might just consider not using event sourcing for such an aggregate root since it is so CRUD heavy.
The second thing you describe seems to be about starting a simulation which will run based on a Specification and produce data during that simulation (I assume). An event driven architecture makes sense here to decouple updating the reporting data from the process that is producing the data. This has huge benefits if you are producing large amounts of data to process.
However it doesn't sound like a Simulation is necessarily the kind of AR that would benefit from Event Sourcing either. For a couple reasons:
Simulation really takes only one Command which is something like StartSimulation
Simulation then produces events over it's life-time which represent what is happening internally with the simulation
Simulation doesn't seem to ever receive any other Commands that could depend on the current state of the Simulation
Simulation is not interacted with by multiple clients/users simultaneously and as we pointed out it isn't really interacted with at all
In general, domain modeling is very specific to each individual project so it's hard to give you all the information you need to build your domain model. It will come as a result of spending a great deal of time trying to understand your user's needs and the problem they are trying to solve with the software. It likely will go through multiple refinements as you develop insights into their process.