In the following article I want to present the idea for a requirements & specification tool with the code name „tiny specs“.
Tiny specs shall be a simple and productive to use requirements engineering tool.
As the name “tiny” suggests, it shall not be a big enterprise solution like Caliber RM, or even an ALM tool like Polarion, instead it should be something better than just using unstructured office tools and awful unproductive web tools.
Essentially it was very much inspired by Polarion. It combines document like editing with structured data capturing, just simpler and less enterprisy.
It will be clearer with some basic wireframes.
The first wireframe shows the basic schema of the UI.
The UI should include the basic flow in requirements analysis activities:
The other tabs Project, Lists and Settings are needed, but the main flow is still recognizable.
The application should be file based. This is a decision I have thought of very long. It will make multi-user scenarios hard, but gives a huge win in terms of productivity and simplicity. It is very much inspired by Quality Spy’s model there.
Side Note: It would be really cool if the menu could be integrated into the window bar like in current web browsers.
This is the start page of the application and allows editing some basic properties of the project.
The second tab shall contain a rather simple functionality: The documentation of the sources of the requirements analysis. In Solages (a specialized tool for ERP rollout projects) I developed a requirements module some years ago. Documenting and integrating the elicitation techniques proved to be a good way to structure the project, since it made the elicitation techniques & processes much more explicit. In Solages it is possible to document complete workshops including meeting protocols and more. For tiny specs this would be way too much. The elicitation support should be a very simple feature supporting the creation of a list of elicitations that include a file link. That link may be a protocol of a meeting, a mind map or other stuff.
The tab contains the chapter tree and the contents of a chapter. You can see that a chapter can contain text parts as well as images and also lists of requirements.
This is pretty much the same what Polarion offers, except that Polarion allows embedding requirements directly into an arbitrary rich text. This must not be possible with tiny specs. Here a chapter consists of different sections and a section can either be plain text, rich text, an image collection or a requirements list. So you achieve a document like view of the specification, but enable structured storage of the data. I will explain the data model later more in detail, but the key point here is that the sections are not fixed, but are depending on the chapter type. The above screenshot shows a „process“ that is almost the same to a process in the requirements analysis module in Solages.
The UI would look completely different with a chapter type „Website-Page“ for a completely different type of project:
Another flexible approach is the structure of the requirements. Actually there is no built in type „Requirement“. There are work items which are extents of work item types. Work item types define fields and so the whole thing is fully customizable. You can for example create an acceptance criteria type, or sub-types of requirements like usability requirement or regulatory requirement with custom fields. We will not make it overly complex here. Text, Number, Boolean and MultipleChoice fields are supported.
The support of the review process is very weakly supported in many requirement tools. Simple word processing tools are often much better, that’s why a review mechanism should be built in that can compete with Word & Co.
At first, reviews are explicit entities and therefore a list of reviews is presented.
This look’s pretty much the same like the Test Runs page in Quality Spy with sub-tabs for opened reviews:
Here it should be possible to annotate the spec just as it is possible in Microsoft Word. The exact workflow for review hasn’t settled yet, this is just a first idea here and I have to think if requirements should be approved one-by-one or if a review should only contain annotations and „defect reports“ of the reviewer.
The file-based approach is no weakness here. STE mode in Quality Spy has shown that a test run can be exported, shared via e-mail, edited in a single test mode and re-imported into the main project. You just need to replace the word „test“ by „review“.
This page obviously shows all „elements“ in a list mode that can be sorted and filtered just like in Excel.
At this point the tool achieves both benefits of MS Word (document like editing) and Excel (sorting & filtering) in one tool. Cool!
I havn’t created a wireframe for the settings page so far. Obviously the chapter types, section types, work item types with their custom fields can be configured here.
Publish and Export
The specification must be exported to something. DOCX would be the nearest choice as a start.
What’s Missing on Purpose
There are loads of features that are missing in this description so far and not because I have forgotten them, it’s because they should not be included:
- Relationships between requirements (Parent, Conditions, tracability Requirement-to-Test run)
- Strict versioning, auditing and base-lining
- Stakeholder-Comments, Discussions
Some projects may need this stuff and then this tool is not for them. But many projects do not need all this stuff, so simplicity rules out feature bloat.
Now, let’s take a little technical view and look at the domain data required by the tool (click to enlarge):
This model is probably not complete but provides a good overview.
Since design goals are similar to Quality Spy, similar technology should be used, that means WPF plus the Purple Box Common Framework that includes support for undo/redo and view model simplifications.
A core problem will be the combination of sections to a document look & feel. WPF offers a great way to do this using data templates for the various section types. The test protocols of Quality Spy also provide a good source of inspiration for the implementation. To provide a rich text editor, a component like TX Text control must probably be used.
Here we go, I’m really infected by this idea. In the last time I evaluated so many crappy tools not being capable being better than Word, Excel or Sharepoint, I really want this simple but yet powerful thing and search for a good developer who can implement this.
The current plan is simple, at first a solution to this flexible chapter approach must be found, from there let’s see what’s possible.
Update: I modified some ideas in version 2.