Lately I’ve been doing a survey of requirements engineering tools (part of that whole doing my job thing). In general this category of tools are called “Requirements Management” tools (RM for short). First, we need to look at the terminology. “Management” refers to managing requirements. “Engineering” refers to creating the requirements (at least this is my take on it).
RM tools for the most part do a good job of managing requirements. You can run reports on them, view them such that you can see connections between them, perform requirements tracing on them (if the tool supports additional features such as test cases and automated testing and linking with code (unfortunately only the very expensive tools support all of these features).
Having said that, let’s look at the “engineering” aspect of tools. Do they help you gather better requirements? That’s easy – no they don’t and if someone wants to debate that with me, I’m more than happy to discuss it. Here’s the thing – no tool we have today can interrogate a user – it’s a human interaction thing. Tools can look at requirements and say “here’s a potential problem” and that’s it. There may even be (again in the most expensive tools) a requirements validation component of the tool but in most cases those only validate the flow of operation or the flow of information and not the accuracy of steps that take place in a given process.
So why am I bringing this up? There seems to be a growing move towards using tools (not just RM tools but in general) to subsitute for processes. Tools are great, they really are. They help make our lives, as software developers (using the term loosely to cover anyone who deals with software development) easier. They make our customers lives easier. But there’s a coming problem that relates to an over-reliance on tools. Our industry needs to step back and realize that soft skills are more important than tools – especially in the requirements area! Being able to talk to someone and write and take good and accurate notes and being able to read body language are more important than any tool. Tools make communication, traceability and monitoring of requriements easier but they don’t make the requirements any more accurate. It might even be nice if schools, on top of teaching all of the technical subjects, started teaching better communication skills (both written and spoken).
Categories
- ▼Application Lifecycle Management (ALM) (242)
- ▼Practices (31)
- ►Software Testing (7)
- Coded UI (3)
- Source Control Management (5)
- ►Software Testing (7)
- ▼Process (32)
- ►Tools (189)
- ►Visual Studio ALM (162)
- Microsoft Test Manager (3)
- SharePoint Foundation 2010 (3)
- Team Foundation Build (14)
- Team Foundation Server (36)
- Visual Studio 11 (19)
- Visual Studio 11 Beta (7)
- Visual Studio 2008 Team Foundation Server (5)
- Visual Studio 2010 (6)
- Visual Studio 2010 Team Foundation Server (9)
- Visual Studio Lab Management (1)
- Visual Studio Team Foundation Server (4)
- Visual Studio Team Foundation Service (1)
- Visual Studio Team System (33)
- ►Visual Studio ALM (162)
- ▼Practices (31)
- Company (23)
- Event (26)
- Videos (2)
- ▼Application Lifecycle Management (ALM) (242)
Archives
Tags
agile (3) ALM (2) Branching (3) build (3) Business (10) Coded UI (2) Database Professionals (4) dev10 (4) Dev11 (14) Dev11 Preview (4) Event (19) Featured (9) Feedback Manager (3) FUQ (10) Kanban (6) Lean (5) Lean Software Development (4) Merging (2) Microsoft Test Manager (3) MTM (3) Northwest Cadence (3) NWC (2) Personal Thoughts (10) Practical Process Improvement (2) presentation (2) Process (2) Process Improvement (4) reporting (4) Requirements (5) scrum (8) Sharepoint (3) Software Configuration Management (2) Software Testing (3) Source Control Management (5) Steven Borg (3) Team Day (2) Team Foundation Build (4) Team Foundation Server (16) teamwork (2) TechEd (2) Technologies (2) Testing (2) tfs11 (2) TFS 11 (2) TFS2008 (2) TFS 2010 (6) TFS2010 (4) TFS Integration Platform (2) tfs reporting (2) Tool (3) Tools (2) user group (8) visual studio (8) Visual Studio 11 (12) Visual Studio11 (2) Visual Studio 2010 (2) Visual Studio Team Foundation Server (2) Visual Studio Team System (7) Visual Studio vNext (3) vs11 (2) VS2005 (6) VS2008 (13) VS2010 (7) VS ALM (2) vsalm (3) vsalm10 (3) vsalm11 (4) VSTS (17)






Pingback: Requirements are not dead. :: Where Technology Meets Teamwork
Pingback: Jonathan Babcock » Blog Archive » The Business Analysis “Artist” and the Requirement Tools of the Trade