Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have been asked to create a traceability matrix that maps between the Requirements and Design document. I am having a lot of trouble working out how I link a single requirement to the design as the link is nearly always 1:M and is therefore difficult to map and maintain. Can any point be in the direction of any examples, or provide some advice on how you manage the matrix in this context. Requirements to Testing makes sense to me, however I fail to see why I need Requirements to Design, apparently this is required for our CMMI3 audit.
Thanks for the help
It appears to me like you are talking about the role of a requirements analyst. There are various tools to help in this process, the leading commercial contender is IBM Doors. Although I believe this can equally well be acheieved using a wiki and hyperlinks within wiki pages to denote dependancy and linkage.
If you have a Requirements Spec and a Design and they aren't already linked in some way then your boss has missed the point of Requirements Management in the first place.
Requirements should guide the design process and be linked from the beginning not merely linked afterwards to keep an auditor happy. Anything you design should be done in a particular way to meet a requirement.
To cut a long story short... Personally, I would stick both the Requirements and the design in a wiki and link them together as I mentioned above. You're basically being asked to make the documentation for a process that either didn't occur or wasn't written down.
The compliance matrix is a two-dimensional table that contains the correspondence of the functional requirements of the product and the prepared test cases. In the headings of the columns of the table there are requirements, and in the header lines - test scenarios. At the intersection is a mark, meaning that the requirement of the current column is covered by the test script of the current line.
The compliance matrix is used by QA engineers to validate product coverage with tests. The TM is an integral part of the test plan.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
i've found many publications that talks about to find Traceability Links and how store them into matrix or other data structure like XML.
I'd like to know if you know any publication on how traceability links are used.
Thanks
A high level (i.e. short) answer is given on the german wikipedia:
With the help of traceabilty data it is possible to measure the quality and progress in a systems development project. This is espicially relevant for the development of security critical systems, as legal requirements such as ISO 26262 or Automotive Spice require traceability to proof that security critical requirements have been implemented and tested in adequate quality. Furthermore, traceability makes impact analysis easy.
refer to https://de.wikipedia.org/wiki/R%C3%BCckverfolgbarkeit_(Anforderungsmanagement)
Fore a more commercial view, you may want to look at the benefits promised by dedicated traceability tools, such as
Validate your links and requirements after every change to be sure to achieve consistent traceability and unsuspicous links.
or
Visualize artifacts and their relations for a clear overview. Navigate between interrelated artifacts with a simple mouse-click and analyze their dependencies.
(In this case cited from https://www.itemis.com/en/yakindu/traceability/ )
Try the following:
Karl Wiegers, Software Requirements 2nd edition, Microsoft Press, p. 357 f.
ISBN 978-0-7356-1879-4
Wiegers emphasizes the use of traceability links in
Certification of software
Change impact analysis
Maintenance
Project tracking
Reengineering
Reuse
Riskreduction
Testing
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Gathering requirements is an essential stage creating software or web applications.
I have searched the web extensively without finding any directions on how to elicit requirements for personal projects. All information i found - including books i read - is focussing on different stakeholders.
So i´m wondering, what would be the best way to 'gather' the requirements for personal projects?
I can't imagine i'm the only one with this question. I have plenty of ideas for webapplications. Since i am the only stakeholder at this time - no users are identified yet, i need to develop a couple of applications for personal use - i find it hard to interview my self to elicit those requirements.
As English is not my native language, apologies for possible textual errors.
You can have a document with all the information you have in your head of the project in a bullet list format called "Project Memoir". Just list all the information & business rules you need to put in the project. You can after that start developing a kind of informal Software
requirements document (as it's for a personal project) containing some essential information for you in the development phase, like a feature list with their description, use cases & scenarios that will help you in testing in later phase, mock up screens for defining the UI look & elements, data elements lists for defining screen contents. Just keep it simple & easy as it's for only your personal use.
Hope that would help :)
The questions are supposed to be a trigger of a thought process.
What makes it any different in case you are the developer next to the stakeholder? Your thoughts are those of a stakeholder and you will have to try to identify your own requirements by this process.
Identifying your own requirements with a structured approach will help you identifying requirements that you would otherwise have encountered during development.
If the sole purpose is not only personal, I doubt whether it is a good idea to start developing. Then you will need to find prospects to interview. Investigate the possible markets.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
It sounds strange, but that's what I need. An effective way to document a Scrum project.
I agree that it's a waste of time to produce User Stories and a Requirements Documents.
But sometimes we need to have the vision of how the software currently works.
How do you do that? Do you know some best practices or case scenarios on this?
Thanks
The short answer is this: you can write anything you want or need to about any project, Scrum or otherwise. Scrum doesn't tell you how to document, but it doesn't tell you not to. The way you document is in itself irrelevant to Scrum.
That said, if you need to understand how the software currently works, a document will not help you. Documentation often lies. If you're trying to understand how the system works, a document will only tell you what people think or want to believe is the truth.
What you should consider, is to use executable specifications and Test Driven Development to prove that what you believe the software does is actually true. automated tests combine documentation, examples and regression tests all into one offer.
There are several kinds of documentation that can help you. It depends on your context which ones you need, and at what detail level. You could also use a tool such as MOOSE to create project specific visualizations of your software at all levels. Some simple documents are:
A story map
Gherkin style high-level features and scenarios
If you've tracked your product backlog items through completion, including acceptance criteria for each you should be able to point to the list of completed product backlog items as documentation. Everything you've programmed should be associated with a PBI, so the completed PBI's document your project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
During the development cycle of a feature, the feature is constantly changing, even after the point where the it meets all requirements (UI improvements, etc...). If you have automated tests for that feature, these changes can break your automation and you will have to rework it. If the feature keeps changing though, it does not make sense to rework automation after every revision. At some point, however, you have to automate it so you can do regression testing. How can we find the optimal time to rework automation? How do we get the optimal amount? My team agreed that we over-reworked the automation of one of our features. One example of a mistake we made was to rework automation right before a conference where we showed the feature off to customers to get customer feedback. We should have known that customer feedback would result in more changes to the feature. Functional testing should have been enough in that case.
Does anyone have any tips or experiences to share?
The general tip would be to come to a consensus on what "done" means for the feature before you you start building it.
If during the build you come across some new tweaks that you'd like to add to improve the feature (or whatever) don't add them to the existing story - write a new one... and make sure that you prioritise it against the other things that you need to be doing.
This is also sometimes, but not always, a sign that you're working with increments of functionality that are too large. Try splitting and thinning the stories further until you can write down some quite concrete definitions of "done" for the feature. Consider automating those tests of "done" before you start building (but don't go overboard).
You might find the Specification By Example book of use.
According to my experience is that the feature you've been developing is not understood by the customers yet, fully.
Separate the feature into small parts like #adrianh suggested.
One more tip for the instable customers: Let them first see the pseudo prototype at first hand, even maybe in the planning meeting (code it directly to html or something easier something like a prototyping/diagramming tool). Let them play with it. This way, you will have an easier time with your features.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
How to write a vision [generally] for some business ? Is it have some template ? any example ?
Business about online ticket services .
What is a 'vision'?
It's such a nebulous objective... I don't see how there could be a template. Unlike requirements specifications, functional specifications etc, there is no accepted understanding of what a 'vision' actually is...
I'd speak to the person who commissioned you to write the 'vision', and ask them what exactly they are trying to achieve and what their expectations are.
Here is a nice article on the Vision. Note that it doesn't have to be a heavyweight document (spend as little time as possible but as much as required). For more formal templates, RUP has some for the Vision artifact.
Karl Wiegers' book, Software Requirements, has an excellent template. I've used in for several projects. It seems a bit formulaic at first, but over the subsequent days and months, really helps a team keep focus.
http://www.amazon.com/exec/obidos/ASIN/0735618798/processimpact
http://www.processimpact.com/books.shtml
The Business Motivation Model is a great source. They define what a business vision is, relate this concept to other relevant concepts in the organisation, and give good examples.
If you are interested in how business requirements are refined into user requirements and how, eventually, they determine what a software system does, you may want to have a look at the OPEN/Metis white paper.
First i warn you : Do not be a template zombie...
Secondly to give you just an idea OpenUP has a nice -non commercial Vision Template...
Check my answer how you can get it : RUP (Rational Unified Process)