Slashdot Mirror
What Software Specification Tools Do You Use?
IronWilliamCash writes "I currently work for a small software development company and for many years we have been using internally built tools for all our software specifications, bugs, change requests and the like. Traceability is a big issue as we are CMMI level 2, and thus our internal processes need to be clear and everything must be documented. We are currently looking into getting a unified solution for this, and after quite a bit of Googling, there are quite a few different options (Contour, Kovair, MKS, Doors, CaliberFM, Accept360, etc.). I was wondering: what do other Slashdotters use in their everyday life? Does it fulfill your needs? And what is the most important part in a specification management tool?"
If there is one thing that can suck the fun out of software development and engineering its requirements traceability tools - My company is CMMI level 5 and we use Doors, Rational ClearQuest and ClearCase, Teamcenter and others. As much as I hate them they have their place and on rare occasions are even useful. My best advise would be to find an integrated suite and avoid having a big hodgepodge of different crap that has to be glued together with third party applications.
Do the absolute minimum amount of work that it takes to fake your way through your audits. Process People are a cost to your business, not an asset. If you invest time in processes, then you are not producing anything that your customers want to pay for - all CMMI/ISO compliance is about their Process People ticking the boxes that say your Process People have ticked their boxes.
If you were blocking sigs, you wouldn't have to read this.
You really need to nail down exactly which platform you're talking about because the choices will differ depending on the platform.
For example, on Windows, you have either Notepad or WordPad. Now, I like Notepad because of its simplicity, but other people like their proportional fonts and formatting crutches. I guess you could splurge and go for something like Microsoft Word, but that's really overkill for most specification purposes.
Now if you're on Linux, you have a ton of choices. The easiest is Pine. If you've used Notepad, you'll most likely be able to pick up Pine pretty quickly. On the other hand, if you like needless complexity, vi might be the specification tool for you. You can do stuff like search based on regexes and copy and paste whole lines of text at once. If you're looking for something more fully featured, a lot of Linux platforms come with Emacs. I think it is a lot like Microsoft Word in that it has too many features that are simply unnecessary, but a lot of people like it.
Of course you're not using a Mac since these are not really programmers' tools. But if you are, I know there is a way to dual boot your system into Windows and get the full power of Windows without having to buy a separate PC. That's a pretty good deal.
When it comes to specifications, completeness, detail, accuracy, and readability are the most important things. Notepad and Pine are excellent tools to help you pound out good specs.
A dedication to process is a substitute for thinking. When the processes become more important than the product, quit. That's the only advice I can give you. I'm aware that's not what you asked, and I'm almost certain you won't listen, but really, that's what I have to say.
I use the output of my test suite. Between the unit, functional and integration tests this provides a great specification of what my software is suppose to do and what the various internal APIs are. And the great thing about the test suite is that I can prove to a certain degree that the software conforms to the spec because the spec itself is executable and actually exercises the software. Specs that you can't prove are accurate are useless anyways, write a good test suite and use testing tools that output human readable results. Since I work in Ruby predominantly those tools would be mini-test, test-unit, rspec and cucumber.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
...a word processing program and a person who knows how to write well? For extra credit, add a change log to the bottom of the document and an effective date up top. If you really need something more complex than that, then hire a grossly huge and expensive management team and let them tell you what to do.
7" x 5" index cards, a marker pen, and lots of conversations between the people who'll really create the software and the people who'll really use it. Everyone in between can be ignored. All that other stuff you think is important... it's ceremony and job creation. Also, read the end of The Dilbert Principle - if you're one level removed from your company's core business (creating a policy and writing code rather that writing code, talking about customers rather than talking to customers, quality teams, process teams etc etc), then it's not worth doing.
This is not a sig
There are two ways to work - one is to plan methodically each and every aspect of what you intend to do for months then spend the 2 weeks it takes to actually do it and the other is to just asking do in 2 weeks and move onward. You seem to be of the first camp...
I'm surprised we aren't hearing from the BPM folks. There's a lot to be said for BPMN and XPDL, which are useful for (A.) communicating with people who understand the basic ideas of flowcharts and (B.) turning those charts into formal workflow definitions that can lead to some confidence that an offshore programming group can return something that resembles your specifications.
There's a school of thought that is firmly committed to the idea that the problems of Big Design Up Front are best solved with Even Bigger Design Up Front. My favorite laugh is when the same people also try to claim that they are doing some sort of "Agile."
My favorite tool for specifying code happens to be a combination of a programming language and the English language.
-fb Everything not expressly forbidden is now mandatory.
My project has a team of about 40 people including people who develop and write our requirements, developers, integration testers, quality assurance testers, and various managers.
We use DOORS for formal documentation including requirements, high level design documents, and manuals. We use Visio to make UML diagrams for detailed design. We use ProcessMax to track defects in code (found by the integration test team or the QA test team), problems requirements, problems with other formal documentation, and to track the results of code peer reviews.
I've been using these tools for about 8 years now and so far they seem to work well for our team. Other teams in our division also use these tools. The only negative is that if I had my way we would use a better tool to generate UML.Our management doesn't see the need for that since the UML usually never leaves the development team and is not included in the formal documentation package we give to QA.
Good luck in finding a solution for your needs!
We use whiteboards, email, MS Word, and Visio Works fine for a company of 30 people with a development staff of two people. And after being in large shops with all the BS you have to do to get something done, I'll continue to forgo the 15% higher paychecks and enjoy the quality of my job instead. Hourly, I'm probably making the same. Per line of code completed, probably more.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
I'd go for anything as long as it's not Accept360.
sounds like you work at a Dilbert work place
We use Lifesuck Greymaker (tm), the best solution for introducing bureaucratic process into your unbridled creativity.
Managers hate being left out. Too bad too ... Agile works quite well and generally creates good software and happy clients. Most of the process software only leaves happy sales-people. (process software sales-people specifically).
In my experience FRAgile is all about justifying business people being too lazy to come up with a spec and then when they finally do give you something (well into development) changing their mind and the spec every five minutes. They say jump. If you're "agile" you are suppose to say "how high" and they can then say "just start jumping and we'll tell you when you're up in the air". Agile only works at all if the developers have a better grasp in advance of the project starting of what the business wants.
These posts express my own personal views, not those of my employer
I agree with all of this. Lots of conversations between developers and actual users, with notecards and pens. Very similar to my own experience: nothing beats discussion for the kind of small-scale projects I've worked on. "It takes a whole village to write an application."
However, I have to wonder how poorly it scales ... I wouldn't trust space shuttle development if it lacked extreme process control.
When does "takes a whole village" (development team) become "takes a city planner with hundreds of subordinates"?
-kgj
Listen. I've spent far too many of my working years dealing with companies that have caught religion of some sort. It doesn't matter which one it is, be it ISO, CMMI, Six Sigma or some virulent form of agile (yes SCRUM people, I'm talking to you); its a religion. Instead of focusing on the business and developing sound processes that fit the business model and the company culture these companies put in place this huge infrastructure hoping that this will make them automatically successful.
It doesn't.
It does kill whatever passion there is though. Yes that goes for agile too but in other parts of the company than the one you might be sitting in.
These days I have a good rule that works - when a company tries to sell me services based on being CMMI level 5 I tell them to far, far away and preferably perform some acts that are illegal in several states. After having dealt with a couple of them I have realized that the only genuine thing generated is a huge paper trail and innovation is dead or dying.
As to your question - I don't know and I don't care. I can only make the friendly suggestion that you look for work in a place that doesn't focus on religious adherence to principles defined elsewhere. I promise you that it'll be more fun, challenging and ultimately interesting.
I've had a wonderful time, but this wasn't it -- Groucho Marx
The dream team - Atlassian.com
We use Doors and I wouldn't wish it on my worst enemy. Its a fairly high end tool and probably a bit too heavy for your needs. One problem we have is that while your version control system can be distributed, doors is centralised and uses huge binary database files.
Also if everybody in the organisation doesn't work towards your CMMI goals no tool will help you.
http://michaelsmith.id.au
the latter is called 'agile'.
Read radical news here
As usual, The Mythical Man-Month cuts to the heart of the matter.
Brooks points out that there is always a specification, unless the project is so inchoate that it's doomed. It may be exclusively in the head of one person in the team, it may be in conflicting versions in the heads of multiple people, but it's there nonetheless.
Some specifications are better than others. A consistent specification is better than a self-contradictory one. A testable specification is better than a vague one. A specification where you can map items to their corresponding tests helps with getting all the bases covered without wasted effort.
If you're free to do so, call the revision control system that holds your tests the "specification tool".
I am convinced that software spec tools are:
a) Prayer
b) Alcohol
c) Fantasy
(You want me to document what?)
An 8 and 1/2 by 11 note-pad to collect my thoughts and good notes.
One single, very short, power-point presentation to satisfy management.
Thereafter, inspiration atop persperation, with the illumination of the congregation caused by instantiation of what was really asked for using the perpetuation of the prior derivation as a starting point...
A revolver is probably the most effective tool for dealing with CMMI.
The tools I *prefer* to use are just cards and good interactions with customers, rapid feedback through short iterations and such. And with my own clients that's exactly what happens.. happy me, happy client.
Where I work at the moment they need slightly more ceremony, so I've found the templates that Karl Wiegers has come up with are super useful:
http://www.processimpact.com/goodies.shtml
High-end, complex tools for managing and tracing requirements are awesome if you (a) build space ships or (b) are a bit potty.. IMHO. I've yet to see any concrete evidence that they add as much value as they suck out of a project. Keep it simple and straightforward.
For requirements traceability, there's also Reqtify. I use it at work for traceability between specs, code, and test scripts. For a smaller company, it might be more within your budget than something like DOORS. It supports parsing of all MS Office document formats, C code, Simulink, ASCII files, and other file formats.
The basic idea is that in your spec, you define a requirement with an ID tag and description, and then create a reference to this ID tag in all associated files that cover the requirement. And then you can generate all the traceability information you would ever need. The format for requirement ID definitions and references are specified by the user as Regular Expressions, so it's very flexible.
My kneejerk response is to tell you not to worry your pretty little head about these questions, since unless you're working on aerospace, medical or government contract code (written in Ada?), this obsession with CMMI will soon put your small company out of business and you'll be able to get a real job at a company that's focused on making products instead of "deliverables". Anyway - the answer to "what is the most important part" is - usability BY THE PEOPLE WHO HAVE TO USE IT. I am involved with some groups who are CMMI level [x], reluctantly and for absolutely no useful purpose (by the time they finish these paperwork deliverables, their product is obsolete). The first step is for requirements to be entered, and this requires cooperation from non-engineers who are used to drafting a free-form Word document, and who frequently work offsite and/or with no live Internet connection, e.g. while on a plane. Note the implication here - for usability by the target people, it should be possible to export, edit offline and reimport data with no loss of audit trail. Further, all of these systems that I've evaluated - I'm most familiar with Contour - impose a structure on the input, and it's usually configurable by means of templates. MAKE SURE your entry template is designed/approved by the [typically marketing] folks who are expected to kick the project off, otherwise you'll wind up with a spec containing everything in the first category box and everything else left blank. I've never seen a CMMI template that was properly structured for non-engineers, btw; they're all designed by CS majors or, worse, documentation control specialists. And without buy-in from those people at the start, you're immediately screwed (unless this is purely a for-show exercise, where auditors, if any, are only looking for some text in every field - in which case go ahead and paste in lorem ipsum and get on with your actual work). I also suggest you hire someone whose sole job is to create and update this paperwork, because it is a spiraling black hole of unproductivity for any project that operates on modern development cycles (it only works with the waterfall model; too bad if you're doing a large consumer electronics project that needs to be released before your chipset goes obsolete and the world moves on) and by having a specific person (persons) assigned to it, you can very easily put a numerical value on exactly how much it is costing you, which might help to kill it before it sinks you. May flights of angels sing thee to thy rest...
We have DOORS at work. Here's my opinion based on project size: Small: e.g. couple of web pages of forms input and produces one or two reports. Don't use DOORS because it's too heavyweight for a project that size. Medium: e.g. too big for someone to understand the whole system in their head. Use DOORS. Large: e.g. multiple teams working in parallel on multiple subsystems. Use DOORS. Very large: e.g. multiple requirements baselines which can all change in parallel. Do not use DOORS here, as it will give you hell managing the different requirements baselines. Also, consider what your customer needs and if they'll pay for additional process. If your customer needs you to deliver things like test procedures which trace to requirements, then a DOORS like tool is a good thing to use. If they just want working software, then you might want to make DOORS optional for the team.
Traceability is a big issue as we are CMMI level 2, and thus our internal processes need to be clear and everything must be documented.
Sounds more like you are at Level 3, "Defined", than 2, "Repeatable"
In my experience, it takes a lot of upper management support to get to Level 3 - either that or they care only about process
As for tools, the clients of mine that have most successfully deployed such tools are the ones using a general issue management tool. Admittedly, this means a PDF or printed document ends up with a page for each requirement/specification/etc, but it allows for easy traceability and each requirement or spec has its own identifying number, which makes it easy to reference in the source code.
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
We use Seapine SCM revision control, TTPro bug tracking and TCM test case management. They also have RM which is Requirements management, and can make up a complete testing matrix. We are a small company, the software is pretty cheap and it rocks ! It is cheaper to pay a license fee for software to get the job done, than to fool yourself and have to keep screwing with an open source implementation and try and tie it all together.
I would like to thank you for the efforts you have made in writing this post. I am hoping the same best work from you in the future as well. Great information put together well http://www.optionpoppers.com/
I know some people that really hate JIRA, but it is great at keeping track of changes and such. It even has ways to integrate with your version management system (including code reviews, via an add-on). Yes, I like it. Yes, I've used quite a few different internally-developed or external packages; JIRA has a bigger footprint than some others, but once you get used to how to move from one step to another, it really makes a lot of sense. And the notifications are great; whenever someone ELSE makes a change, you get an email if you are attached to the project (developer, analyst, etc.) or if you have marked it as "I want to watch this project."
First I hope that your companys contracts have CMMI as a requirement, otherwise, it's far more trouble than it's worth...
There is a shed load of evidence that engineering certification will cause more problems that they solve. I.E. People don't even looking for real issues because the process will save them...
Even heard the comment, "We don't need good programmers because our engineering is so good.", that's the real problem.
I once worked at a CMMI obsessed company, the ratio of engineers to programmers was about 5-1, that's one in six people doing the work(And to get the engineers to admit that changes where needed to designs, almost more trouble than its worth; few where ever programmers, and from my perspective, if ya can't code, ya never going to be a good engineer/architect)...
Having said that, I still use many of the practices, unit testing, a variety of UML tools, SCM, there is tons of grate tools to help programmers, and if your using eclipse, all the good tools are available as plugins.
At the end of the day, CMMI also means, extremely low productivity, but if the contract requires it...
But with good programmers you can negate the need for such extreme engineering...
I worked for a large defense contractor that writes a lot of complex software on secure systems. The only quality control tools I ever saw used were PMD, audits/standards put forth by DISA, and in depth peer software reviews.
My understanding is that at some point they decided that products like Contour are 95% bullshit and 5% use, which can be replicated by more efficient processes.
I did software development and IA, so I had a fair bit of knowledge about the processes used.
while(1) attack(People.Sandy);
OSRMT seems to work. Anybody actually using it?
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Let me recommend a book : "Lean Software Strategies: Proven Techniques for Managers and Developers". It containes throrough analysis of craft, mass and lean production strategies and their reflections in software (CMM being on the mass side = already obsolete approach). If you can't abandon CMM because of market conditions, think about embracing CMM with as much lean as possible as Peter Middleton describes, and find auditors who would understand and allow you advance on CMM scale without sacrificing productivity and adding waste to your process. In terms of tools, good issue tracking system with customizable workflows is what I recommend.
Why don't you use the good old CVS?
Govt must constitute a panel to rewrite US Constitution and Quran
A tool won't do you any good if you don't use it. You should look for tools that fit your team's culture. If you can afford the time to do it, pick the tools that look the most promising to your team and give them a trial run. It's hard to beat actual experience with the tools and the supporting processes. I understand that this costs time and other resources but the commitment to a toolset/process will be more expensive, especially if you choose one that you can't live with. That also applies to not not getting anything. The tool that works for one project or team does not necessarily work for the next.
I really mean common sense coupled with Murphy's laws. If you are so shit scared of talking/saying/using common sense, the thing that helped the humans come out one up, and say "fuck you CMMI" you don't belong here.
I have a nice euphemism for these fucktard called consultants -- insultants.
The AC posted a quote from the Agile Manifesto
In the agile world blaming is largely seen as counter productive - in Scrum you make the fact that you "forget" to do something visible as soon as possible by interaction with the "culprit" on a very frequent basis.
In the more classical way of working you do a lot of book keeping so that after months or even years you will be able to blame somebody for doing something wrong. That is butt covering, isn't it? It doesn't help preventing or solving the problem in the first place.
Perhaps it could help learning from past mistakes then? In theory perhaps, my experience is that people rarely dig into that kind of data to solve current problems.
Yes, it's a programming language. That's the extra advantage: you can execute your specifications. For an example of how it works, take a look at "Functional Specification of JPEG Decompression, and an Implementation for Free" (1995, Jeroen Fokker).
If you already own MS server 2003 or 2008 or 2010 - WSS 3.0 (the free version) has great discussion board for release notes, development notes, release notes, version control on document libraries and RSS feeds from all to our favorite RSS reader. I disagree with the process haters. You can crash a space shuttle without processes. If you want to move fast with no accountability, fly solo, but still, don't forget to file a flight plan (oops there's a process). I have a few posts on WSS 3.0 at http://gregstechblog.wordpress.com/
Consider BDD. If it is at all feasible in your environment, go for it.
It will considerably reduce that gap between specification and coding, since the requirements are expressed as tests.
I have been developing software for ~15 years having been employed with only 4 companies, but 3 of those were consulting companies and as such I have worked at dozens of companies. Some at CMM levels (above 1) and some ISO and some with aboslutely no process.
It's been my experience that most companies that want process improvement view it as a way to protect the company. Management's view of process has a primary goal of documenting everything. Management theorizes that if this occurs, then employees can be swapped, let go, hired with minimal interruption to the company's profits.
Management's secondary goal is to gain consistency for their product. This is a very distant secondary goal compared to the primary goal.
Unfortunately for Management, Engineers by their nature aren't stupid. They recognize what's happening when there is a "process initiative" started at a company. It's an effort to lessen the impact of any one individual's contribution to the company as a whole. In order for a process improvement program (PIP) to gain wide acceptance at a company, the Management of a company has to show its employees that they are valued and will continue to be valued and demonstrate to them that this faith is justified by deeds and not just words. Otherwise it truly is just a mechanism that accelerates the outsourcing of labor. Of course, often Management finds out too late that individual contributions do matter, not all Engineers are created equal, some are more "equal" than others. But by then it's too late, they've left and started their own company to compete against them. (Thus starting the entire process over again - Matrix style).
Consumers of products from process-based companies, generally win, either through better quality and lower cost, or just lower cost (because the labor was outsourced). It's difficult for the consumer to know which occurred.
Always remember a quote from someone famous: "The ideal company has 0 employees".
The other irony WRT to "process improvement" that I have experienced, first hand is that Management is often exempted from it. That's usually a bad omen.
As a software engineer working in a Class III medical device company, specifications, process, documentation, and traceability are a given. My team is currently evaluating several ALM packages that handle requirements, test case management, issue tracking, source control, and tracing. We have evaluated Polarion, Contour, and Seapine. Countour was found to be a bit lacking and required integration with some other tools to get to a fully integrated ALM solution, so we are no longer considering it as an option. Our choices are now down to Seapine and Polarion.
Question to fellow Slashdotters:
Does anyone out there have any experience with either Seapine or Polarion? If so, what has your experience been like?
The INCOSE Tools Database Working Group (TDWG) has a Requirements Management Tools Survey: http://www.incose.org/productspubs/products/rmsurvey.aspx The responses are self-reported by the tool vendors, but they appear to be mostly accurate. This survey could help you choose between requirements management tools to help you find one that will fit your needs and your business style.
If you're using CMMI as a religion, you're using CMMI wrong.
If CMMI is causing you more problems than it's worth, you're using CMMI wrong.
If ALL of your projects are generating a huge paper trail, you're using CMMI wrong. (Choose better "focus projects" for your appraisal.)
If CMMI is stifling innovation, you're using CMMI wrong.
If CMMI makes you focus on principles developed elsewhere instead of your business objectives, you're using CMMI wrong.
If CMMI isn't helping you improve your product quality, you're using CMMI wrong.
If CMMI isn't helping you, you're using CMMI wrong.
But that comes as no surprise. Most companies seem to be using CMMI wrong.
CMMI is a tool. If you hold it right, if you swing it right, if you have enthusiastic people skilled in using it, the tool can give you good results.
If you inflict the tool on reluctant people who don't have any experience in using it, you will likely get really bad results.
You should only use CMMI if you're serious about improving your software engineering processes. Don't blindly chase arbitrary numbers or timetables. Use it in ways that help you and don't use it in ways that harm you.
CMMI prompts you to think about which of your projects should use best practices from industry, like using requirements tools and bidirectional requirements traceability. You should use some of these practices on some projects, and you should avoid their use on other projects.
The deep universal problem in software is in 98% of outfits, there are no designers and nothing resembling design artifacts. A proper specification involves exactly what the problem is, what the user needs are, and how it will be solved for the client (mostly this is something a designer/architect should do, and it can take many forms). If you are building a building an architect comes up with a cogent, wholistic plan of how to erect the building. The sad, but true fact is that in software there are no architects, and (raw) user needs are thrown down in excel (or something more traceable) and sent to the "builders". This process is equivalent to building construction in 100B.C.
In FACT requirements should be WHAT YOU REQUIRE TO BE BUILT when you have a clear developed understanding of the user solution. The traditional excel/bugzilla/whatever_tool requirements in text form are a transformation and expression of what it takes to build the DESIGN. Chop up the solution into "sorta atomic" req's. There are of course technical specs which would be mostly for the internal team (how big pieces are architected and fit).
The big problems in software have nothing to do with tools, nothing to do with traceability, nothing to do with agile, and everything to do with management having no idea how to envision and specify a transformation of user needs into solutions. The lack of design is keeping the industry in 100BC.
The strength of a dev's (negative) reaction to this is evidence of the extent of the problem. Most cannot even "see"? how design is the lack of a problem. As a dev turned designer (it just so happens this was what I was fated to do), I have seen this is the core issue - and the most dev teams have the most cursory understanding of how to solve user problems, and how to understand users. The best evidence for this approach is that Apple is the #1 tech company in the world and #3 company in the world after Exxon Mobil and Petrochina. Everything I have said in this email is "their secret sauce."
Do NOT use Cognition Cockpit. It's buggy, slow, and out-of-date. But for some reason, they seem to be able to sell it to corporate higher-ups so long as no engineers get involved in the decision. Then they make those companies let them use their logo on their web site. So the CC web site lists all these Fortune 500 engineering companies on it - but I bet most of them don't really use or like the software at all.
"what is the most important part in a specification management tool?"
Its non-existence.
If you are really required by regulation to have one, strive for simplicity.
I got my Masters degree in software engineering which was largely all about project management. We even took a course from CMU on a topic that was a theory about proving the "correctness" of code without testing it. Bottom line is that when all the mucky-muck non-programmer BS dust settles, you still have to write the code. Of course, once you get a few programmers together who are working on projects that overlap, you need some way of managing the effort. In terms of butt-covering, I've heard it said that when a small company hires more than one lawyer it's time to leave.
Nothing replaces a team of guys dedicated to requirements. And a methodology. I run a critical in house application with almost 4 million lines of code (language and infrastructure are irrelevant), which has been built in multiple parallel phases over the last 10 years. We've been able to represent the solution to business' problems in code without having significant defects, or rework for that matter.
Here's all you need: (and good luck, becasue doing it right isn't easy by any means).. this does not take into account agile methods.
1. Business buy in. Stakeholders who have a vision and the will to see it through to the end. It's helpful if they have money. :)
2. A requirements leader, and depending on your needs at least 1 other requirements guy. They need to be _able_ to understand the business, listen well, be organized, and drill down in the finer points of whatever so as to eliminate ambiguity. And get same onto paper.
3. A scribe. He doesn't care about the requirements so much, he just writes/records everything. Like a court reporter. He is also responsible for the minutia of the document maintenance. Keeping versions aligned, etc.
4. At least one technology lead. His role is twofold, to tell the business when things aren't technologically feasible (and offer them options), and get the development team started on tech prototyping / r&d work ahead of actual technology design and coding.
5. Optional: a dedicated test team. Myself, I don't use them. I trust the requirements people and the business to test, and ultimately the business needs to be satisfied so get them involved in Unit Testing and simulation. You already have their buy-in.
Then:
6. Meetings to discuss requirements. With agendas, goals, and takeaways assigned to people.
Outputs:
7. A document that describes the business problem and business environment. With list of approvers, a TOC, well organized chapters, bullet lists, diagrams. Whatever. This is the scope document, and when the business signs it it becomes the bible for the project. Business is the owner of this document.
8. A functional document, that describes how the application will function. :) with a matrix mapping the sections back to the scope document. Screen prototypes, descriptions of interfaces, human language descriptions of the business logic. Requirements team owns this.
9. (optional but we have several) Architecture document. What is the operating environment? Languages? Protocols? SLA? Can be combined with coding standards. Has a loose mapping to the scope and functional docs. Project architect owns this.
10. Technical specs document. Describes the code structure. The functions/methods/objects that will be encoded to solve the business problem. With a mapping back to the functional document. Project architect owns this.
11. Test scripts. Technical and functional. Map back to the functional and tech documents, and the architecture doc too. Negative test cases as well, make sure you test the hell out of your exception logic. Input validations, etc. Authored by the requirements and business teams, or your dedicated tester. There's no end to what you can test. But keep doing it and make sure that the business is involved and then using the test system as if it were production.. mirror testing. Feed it production data. Did I mention production simulation and testing the shit out of it?? and that the business stakeholders need to do it and own it and sign off on it? Test that code, it deserves it.
12. A sane request for change process. Avoid scope creep but be reasonable.
The IBM crowd is going to hate this, but you don't need to be constrained by clear case, and rational rose, and rational functional tester. You can accomplish the same thing, with better results with smart humans, good relationships, and Word/Excel or whatever your choice of document tools is. Your tech team needs to be on the ball for coming up with testing tools for your technology stack.
Good luck.
Huh?
We used to use spreadsheets and the like, then we tried CaliberRM for a year or so, but now it appears that we settled on Microsoft's Team Foundation Server. We have several teams around the world and are finding TFS to be very useful in keeping track of requirements, test cases, strategy documents, etc. We also use Rally for our development tracking. Good luck!
vi and a brain
Enterprise Architect is very nice, since you can do forward and reverse software engineering with it.
However, if you do not have the budget allocated for it, a good compromise is StarUML,
which became very nice and usable lately and has the same "feeling" and menu-driven approach
like the old Rational Rose and Enterprise Architect:
http://staruml.sourceforge.net/
http://sourceforge.net/projects/staruml/files/staruml/5.0/staruml-5.0-with-cm.exe/download
As for Rational Rose, the first original version was very good with some known quirks until it
became IBM Rational Rose and was converted into a "super Eclipse" plug-in.
So, if you enjoyed drawing UML diagrams in the old Rational Rose,
then Enterprise Architect and StarUML are the tools that you are looking for.
And if you do not like to draw with a mouse then Graphviz Dot and a good text editor is for you:
http://www.graphviz.org/Download.php
For tracking issues / documents and schedule,
I can recommend either BugZilla, Mantis or BaseCamp:
http://www.bugzilla.org/download/
http://www.mantisbt.org/
http://basecamphq.com/
As for the actual writing part, your company should already have a good set of Word Templates,
to document the actual Sofware Requirement and Specification (SRS), Sofware Design Document (SDD),
Change Request Document (CRD).
Once, you got those set up, then we mostly use MantisBT or BaseCamp to share, comment and track them.
As for producing code documentation, the choice are: Doxygen, JavaDoc, NDoc, JsDoc:
http://www.doxygen.org/
http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html
http://ndoc.sourceforge.net/
Yep..Back Of Napkin works for me.
Helps to have a 'Flair' type pen as narrower ones tear the napkin.
Remember that your first ideas are almost always the best ones and you'll return to them after you're done trying to be 'cute'.
For longer sessions that require more napkins...do buy more rounds.
Having recently reviewed and selected a software development toolset where traceability was our #1 priority requirement, I would suggest checking out SpiraTeam or SpiraTest. It does everything you probably need and can tie into lots of different other programs if you like as well. It's also very reasonably priced.
There isn't a CaliberFM you can find them @ Microfocus.com
RE: MKS. Happy to put you in touch with a contact that can see if there is a match with your challenges.
Let me recomend you our tool named Kanav: www.kanav.com. Kanav is a tool oriented to the CMMi Process, in Kanav you can define your own process and define projects that implement your this process. Traceability is a big issue but Kanav solve it efficiently. you can go to www.Kanav.com for more information. What is Kanav? Kanav is a suite of Web tools (multi browser and multi database) for project management. Within the Project Office niche, Kanav is the project management, requirement and request management, and configuration and decision-support management tool which best integrates to legacy applications due to its open architecture and modular concept. Kanav is a platform that allows you to manage development teams, both on-site and offshore. Kanav is a product created by Vates S.A., currently commercialized, maintained and developed by Kanav S.A. (www.kanav.com), whose original conception was addressed towards the creation of a tool that enables software project follow-up and provides all the information an IT company needs to track its global activities. Vates S.A built Kanav with the idea of setting it up as the IT companies' ERP. Kanav Platform provides the integration of different modules on which you can manage from end-user’s needs by means of recording, analyzing, evaluating, and approving requests as well as assigning people responsible for performing the required tasks, and carrying out the tracking, control and closing of work assigned. SOLUTION APPROACH Kanav Platform is a suite of tools designed to integrate and manage the key areas involved in software production. Kanav proposes the standardization of the disciplined processes and the use of an integrated suite of tools as a solution to the problems encountered in software production. In this way, the repeated application of solutions to similar problems is guaranteed, facilitating the measurement of results and the path to reach a continuous improvement.