Categories
- Agile (6)
- Architecture (1)
- art (2)
- Big Data (1)
- books (11)
- Cars (1)
- Change (9)
- common sense (3)
- Contracting (1)
- Cool (1)
- Design (5)
- development (1)
- emotions (3)
- entrepreneurship (2)
- google (1)
- great quotes (2)
- happiness (1)
- innovation (3)
- IT (8)
- IT Architecture (3)
- Knowledge Transfer (2)
- leadership (3)
- Lean (1)
- links (1)
- literature (1)
- lyrics (1)
- management (9)
- Media (1)
- Negotiating (1)
- networks (1)
- people (5)
- Personal Improvement (8)
- planning (5)
- productivity (3)
- Programming (1)
- Project Management (23)
- Projects (1)
- psychology (3)
- Requirements (5)
- Risk (2)
- scrum (2)
- strategy (6)
- struggle (1)
- summer (1)
- teams (5)
- Test Automation (3)
- thinking (5)
- Training (2)
- Travel (1)
- waterfall (4)
Tag Cloud
Agile
Architecture
art
Big Data
books
Cars
Change
common sense
Contracting
Cool
Design
development
emotions
entrepreneurship
google
great quotes
happiness
innovation
IT
IT Architecture
Knowledge Transfer
leadership
Lean
links
management
Media
Negotiating
people
Personal Improvement
planning
productivity
Programming
Project Management
Projects
psychology
Requirements
Risk
scrum
strategy
teams
Test Automation
thinking
Training
Travel
waterfall
So many requirements, so little understanding
Posted by Rich Crowley in IT, Requirements
Business requirements, high level requirements, user requirements, functional requirements, user interface requirements, detailed requirements, system requirements, non-functional requirements, interface requirements, software requirements, business process requirements.
The good news to be taken from the list above is that there is no shortage of ways to think about requirements. The bad news is that a list of this size implies many different definitions of requirements which must be at least partly contributing to poorly defined requirements and their impact on projects. With so many definitions, is it any wonder that business and IT staff disagree on what constitutes well defined requirements.
I believe business staff are quite capable at defining business requirements in plain english. I believe these are often very high level but that’s ok. I also suspect IT staff are quite capable at defining requirements that much closer to the system that is supporting the business.
However, this leaves an awfully big gap where business lingo needs to translate to systems lingo and this is where most of the definitions above come into play. It’s also where both sides often end up hating each other. As a result, I believe it’s where most of the pain and hard work is, and where most of improvements can come from in requirements definition.