Requirements management for a very small medical SW company

M

Micked

#1
My client maintains a SW application which can be described by approx 100 high-level requirements (market requirements specification). At the next level of detail there may be about 500-1000 software requirements.
The existing specification is out of date and needs to be re-written.
There will also be traceability to test cases needed.
Once the specifications are written, they do not anticipate too much change over the years, only minor additions.
What is your recommendation for managing this amount of requirements?
- Word: Looks nice, easy to add descriptive text. A pain to maintain?
- Excel: Easy to get started with. Easy to expand with new coumns if new attributes are invented. Can easily be turned into a poor man's database. Lacks backup and history features. Easy the corrupt information by mistake.
- One of the commercial entry level requirements management systems out there. They always lack some features...
- Going with a mid-range system. For installation and maintenance see below, and license fee's may be in the k$ per seat per year.
- Going all the way to a full-blown system. My client has a license for Microsoft Team Foundation Server, but the installation and maintenance efforts are not trivial.
They definitely do not have the manpower to spend on server maintenance for the higher range systems.
Why can't I find the holy grail of requirements management systems???
 
Elsmar Forum Sponsor
K

khuengo

#2
All information and comparisons you need for requirement management tools in the world can be found in the INCOSE website (I could not paste it here because my posts are under 5)

I think the most popular tools are Doors and Requisite Pro. I am using ReqPro to manage 2000+ software requirements. Not extremely great product but fairly easy to use. The license cost os about $2000 for 1 user license. There is a good book on req management with ReqPro that you can buy from Amazon.

FileMaker Pro is another tool not written for requirement management but can do the work fine and it is way cheaper than ReqPro or Doors.
 

yodon

Staff member
Super Moderator
#3
I'm pretty much in the same boat with khuengo. We have both ReqPro and DOORS. My experience is that for a small shop, ReqPro is more efficient. I've seen that DOORS tends to require a bit more overhead - you can do more with it but you have to have the skills, time, expertise. With ReqPro, I've found, you can get started quicker and it's met all my needs. And I like working in the deliverable rather than in the database. Both are sold by IBM now. As khuengo pointed out, there's the (one time) license cost and then you decide if you want the yearly maintenance cost.

You certainly DO NOT want to try to use Excel or Word to manage. As you've already pointed out, it's way too easy to mess things up with a manual process.
 
B

blewispunk

#4
We use Jira from Atlassian for our software issue and feature tracking and have leveraged it's functionality to also track our hazards, requirements, tests, and executed tests. It wasn't designed for this but for a smaller medical device manufacturer it actually works very well.

The area we have struggled with this a bit is the approval of the requirements, etc. How are others dealing with this (I'm assuming doors and reqpro have part 11 compliant electronic signatures but if someone designs a solution in filemaker for example)? We currently have status' for our items in Jira that are able to be locked down when in review and we attach a link to a query that returns all the records (requirements, tests, etc) under review in our doc control software which has electronic signature capability. When approved (in the doc control software), our QA group uses the filter to grab all the records (in Jira) and move them to released in Jira, which is another locked phase that only QA can change. Ideas for other approaches?
 
M

Micked

#5
Thanks for your feedback, folks.

INCOSE is a good source of info, but I haven't found my ideal light-weight tool there yet.

I have been living with Doors for the last 8 years, I know you can do everything and a little more with it. :cool:
We also had a full-time team maintaining it...
The guy next to me was constantly hacking Doors scripts to make new features. That's not where my client wants to go, if you see what I mean.

ReqPro was my tool at work before that. It's still a pretty hefty application for a team of only a handful people. I also remember some scalability issues, but they may be solved by now. If you check Rational's (IBM that is)website, ReqPro will migrate to their new jazz platform if I got it right. Then we are in Eclipse country if I am correct.
My client is a Microsoft shop, so that's a hefty change, again.

blewispunk, I have gotten the advise to use Trac for requirements management, that should be similar to your Jira setup. I believe you enter a requirement as an issue (or whatever the atomary unit is called in Jira) and then you can play around with state changes, add comments etc.The question is how that scales up to about 1k req's? A second issue is how to get decent requirement spec printouts.

As for your part 11 thoughts, I have read a bit on the "hybrid approach". This is all about managing your data electronically, but make printouts and sign with real ink at certain points in time. That could be project toll gates, sprint completions or whatever suits you best. In that approach you can work efficiently day to day, but you have to produce paper and ink for the audits.

As for Word and Excel, I am currently advocating Excel just to capture the requirements and get going. Which ever tool they may choose, there will always be an easy import from the spreadsheet.

I would be interested to know if there is a team of no more than 4-5 people out there, and what you are doing about requirements.
 
B

blewispunk

#6
Hey Micked,

It sounds like we are in similar situations. Our engineer who has done all the work with Jira came from a shop that used doors and it was just too much for us (in cost and complexity). We needed something that we could setup to meet our needs - and all the engineers and developers already were using Jira a lot so it seemed a logical solution. Our current implementation has about 400 requirements in it already and we just started doing this the end of 2009. We will have a couple thousand in there by the time we transfer them all from our MS Word specifications (what we used previously).

Your understanding of how we are doing it is correct. We created a new project in Jira for Requirements. Originally we had another project as well for Test Protocols but we ended up rolling these together (now every requirement has a test written with it as part of the same record). These export very nicely into Excel as long as you have logical fields to sort on. We created a field of "User Function" where we categorize the requirements by and that is what we use to generate a requirements spec / test protocol. We use the linking in Jira to connect Component Requirements and tests to at least one Hazard or Product Requirement. We are also now doing our test data entry in Jira as well so we have "Test Instances" where we clone the released Requirements and Tests and then document our results in Jira. The nice thing about this is the ability to create a full traceability from hazard analysis through requirements, tests, and test data. For example, this makes it easy for us to demonstrate that all of our hazards have mitigations and that all of those mitigations have passed testing.

I just wish there were part 11 signatures in Jira. We are still keeping everything electronic by leveraging our doc control system which has part 11 sigs to do the approvals but it would be nice if this could all be done in one system.
 

Jim Ivey

Grand Avenue Software
#7
My client maintains a SW application which can be described by approx 100 high-level requirements (market requirements specification). At the next level of detail there may be about 500-1000 software requirements.
The existing specification is out of date and needs to be re-written.
There will also be traceability to test cases needed.
Once the specifications are written, they do not anticipate too much change over the years, only minor additions.
What is your recommendation for managing this amount of requirements?
[...]
They definitely do not have the manpower to spend on server maintenance for the higher range systems.
Why can't I find the holy grail of requirements management systems???
Just out of curiosity, since you in a later post mentioned "sprints" and might know something about agile software development, have you considered dispensing with a separate "requirements management" repository altogether and documenting your requirements as automated tests?

Our development organization employs Extreme Programming as its methodology, and has invested in a test-driven development model since the company was founded in 2002. The complexity of our software seems roughly comparable with your scenario... we are a small organization (4 people) with approximately 700 high-level requirements, each backed up by high-level "acceptance tests", which are in turn backed up by approximately 10000 low-level "unit tests". Rather than keep the requirements in a separate document, we annotate the corresponding acceptance test with an attribute that contains the English description of the requirement (in our lingo called "acceptance criteria").

Prior to shipping a release of our software we run all of the tests and generate reports that include the list of all of the acceptance criteria, with traceability to the corresponding acceptance test, and the test results that shows all acceptance tests and unit tests passed.

Among the many benefits of this process are:
- We identify regressions immediately during the development process, as we have integration builds running the entire test suite anytime new code is checked in.
- If a customer is curious about how we verified a particular requirement, we can show them the exact automated test that was executed to satisfy that requirement.
- Because the tests are written in code there is no ambiguity or possibility for confusion on the part of a human "tester".
- The rigor introduced by the test-driven development process (add new test, run test to verify it fails correctly, add code, run test to verify it passes, run all tests to verify no regressions, repeat) has resulted in incredibly high levels of quality for our software.

As a minor side note, because the acceptance criteria (requirements) are annotated directly on the test code, they benefit from the same robust change control mechanism that we rely on for software development (in our case, SourceGear Vault).

Anyway, I just wanted to offer a different perspective on the matter. Before this company I'd spent fifteen years in traditional software development, working with the types of tools you described above. Hopefully I'll never have to go back.

Good luck.

Jim Ivey
Grand Avenue Software
 
M

Micked

#8
Very interesting feedback, thanks.

Blewispunk, seems we are thinking along the same track. Your setup sounds very nice. Did you experience any scalability problems with JIRA?
Is it the "User function" field that is the key to filter out the requirements spec?

Jim, your shop seems to have come a long way to implement a TDD workflow. Congrats! Implementing a full automated test suite may be a bit too much to chew on for my client, but it sure would be nice to have.

I suspect you still need to assemble all "acceptance criteria" in some form to show that you have design inputs, speaking FDA-ish. Do you filter them out and put a printed and signed copy in the drawer, or do you rely on electronic signatures?

I don't think my client will "go all the way agile", but I am trying to persuade them to think in shorter sprints in stead of e.g. 6 month release cycles.
 

Jim Ivey

Grand Avenue Software
#9
Very interesting feedback, thanks.
I suspect you still need to assemble all "acceptance criteria" in some form to show that you have design inputs, speaking FDA-ish. Do you filter them out and put a printed and signed copy in the drawer, or do you rely on electronic signatures?
You're right that while we could probably just rely on the repository of tests, it's not very user friendly. So as part of our build process we have an automated tool that scans the test suite and produces a report that lists all of the acceptance criteria, along with the name/location of their corresponding acceptance test. We then archive both the report and the test results along with some other documentation into a "validation package" for that release, and make it available to customers.

I don't think my client will "go all the way agile", but I am trying to persuade them to think in shorter sprints in stead of e.g. 6 month release cycles.
Our current release cycle is roughly every eight weeks, though it's just an arbitrary window. That seems about the highest frequency that our customers can actually digest. We also publish weekly development builds to a set of hosted "evaluation sites" (our software is web-based), so that customers can constantly review new features and provide feedback prior to release, to make sure that our acceptance criteria and tests actually reflect intended use.

Anyway, one thing to consider is that even if you choose to go with a separate requirements management tool, there's no reason why you can't adopt an agile approach to using it. They're obviously not mutually exclusive.

Take care,

Jim
 
Thread starter Similar threads Forum Replies Date
Le Chiffre Online training available for ISO/IEC 17021-1: Requirements for bodies providing audit and certification of management systems Training - Internal, External, Online and Distance Learning 3
N Risk Management besides mandated FDA requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
D Customer and Company Specific Requirements for notification of Customers of a change in Management or Key Personnel Customer and Company Specific Requirements 3
S List of requirements for Management Review in IATF 16949 IATF 16949 - Automotive Quality Systems Standard 10
T Risk Management Report as per MDR Requirements EU Medical Device Regulations 4
J IATF Minimum Automotive Quality Management System Requirements for Sub-Tier Suppliers IATF 16949 - Automotive Quality Systems Standard 12
J IATF 16949 container management requirements? IATF 16949 - Automotive Quality Systems Standard 2
S IATF 16949 Supplier Management - Supplier Tooling Requirements Supplier Quality Assurance and other Supplier Issues 1
T IATF 16949 Quality Management System (QMS) Scope Requirements IATF 16949 - Automotive Quality Systems Standard 11
L Auditing Top Management - Meeting Competency Requirements and Questions to Ask General Auditing Discussions 11
R Document Management Software : Validation and other requirements Medical Information Technology, Medical Software and Health Informatics 8
M Requirements of the quality management system - TS 16949 clause 5.6.1.1 IATF 16949 - Automotive Quality Systems Standard 1
T Changes in ISO9001:2015 to the requirements for a management representative ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
somashekar Applying legal requirements in hazardous waste management. Miscellaneous Environmental Standards and EMS Related Discussions 1
K Understanding Risk Management Requirements according to AS9100 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 11
M EN 62304 and Quality Management System Requirements IEC 62304 - Medical Device Software Life Cycle Processes 4
I Contingency Plan that meets requirements of API Q1 Quality Management System Other ISO and International Standards and European Regulations 3
C ISO 13485 - Documented Requirements for Risk Management ISO 13485:2016 - Medical Device Quality Management Systems 6
somashekar What are the ISO 13485 documented requirements for Risk Management? ISO 13485:2016 - Medical Device Quality Management Systems 13
A Risk Management - HIRARC Form Requirements Occupational Health & Safety Management Standards 4
E ISO 14971:2009 Risk Management Requirements CE Marking (Conformité Européene) / CB Scheme 2
C Supplier Management Requirements - AS9100 vs. ISO13485 Supplier Quality Assurance and other Supplier Issues 5
D CAPA FDA Requirements and Guidance related to the Risk Management File 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
O Are the ISO and CE requirements same as FDA for a Quality Management System? Other Medical Device and Orthopedic Related Topics 5
B ISM Code (International Safety Management Code) Requirements and ISO 9001 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
M Quality Management System Documentation Language Requirements AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 13
D ISO 17025 and Calibration Laboratory Risk Management Requirements ISO 17025 related Discussions 1
N Legal Requirements for a Quality Management System ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
V Implementation and Management of Customer Specific Requirements Customer and Company Specific Requirements 4
C ISO 14971 Clause 9 Requirements - Post-Production Monitoring and Risk Management ISO 14971 - Medical Device Risk Management 7
K Configuration Management - AS9100 Requirements AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 11
S TS 16949 Clause 5.6 - Management Review Requirements - Without a meeting? IATF 16949 - Automotive Quality Systems Standard 17
S Management Representative Requirements and Responsibilities Clarification ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
M ITIL vs. ISO 20000 Change Management Requirements IT (Information Technology) Service Management 3
E Compliance with AS9100 Rev C Risk Management Purchasing Requirements AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
Randy ISO 50001 Energy Management Systems - Requirements Sustainability, Green Initiatives and Ecology 29
M Management Review Input and Output Content Requirements Quality Management System (QMS) Manuals 2
S What's the meaning of "Quality Management System Requirements" in 7.4.2 (c)? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
S Special 510k for Data Management Software Document Requirements IEC 62304 - Medical Device Software Life Cycle Processes 1
C Configuration Management requirements if this facility is not design responsible AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 9
O Management Review Inputs and Outputs - AS9100 Registration Audit Requirements Management Review Meetings and related Processes 16
A ISO 9001 Project Management and Risk Analysis Requirements - Construction ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 13
J Management Representative Requirements - ISO 9001 - 5.5.2 Clarification ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
G Requirements for Implementing an ISO 9001:2008 Quality Management System (QMS) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 16
W MR (Management Representative) Requirements and Responsibilites ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
L ISO13485 Cl. 7.1 Process Flow (Product Realization & Risk Management requirements)? ISO 13485:2016 - Medical Device Quality Management Systems 2
G ISO 17025 definitions - Requirements for document management system ISO 17025 related Discussions 5
G FDA Risk Management vs. CE Risk Management - Requirements Differences 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
C Compliance with AS9100 Configuration Management Requirements AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
A Simplified Explanation of the 8 Quality Management Systems Requirements ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6

Similar threads

Top Bottom