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
Requirements – I Got Nuthin!
Posted by Rich Crowley in IT, Requirements
After 20+ years in the IT business working on projects, I’ve decided I really don’t understand nearly enough about requirements and am going to make the harsh judgement that most IT staff who are either creators or consumers of requirements, as well as business people from whom requirements are supposed to originate, don’t know much about them either. So…I’m takin’ to readin’ to see if I can learn some of the discipline around requirements in a very orderly way.
One of the more intriguing insights I’ve gained so far is the many different flavours of requirements that exist. For example, one author suggested business requirements should articulate high level business directives, followed by user requirements which outline how the user will interact with a system to achieve the business requirements, followed by software requirements that explain how the software should be engineered to meet the user requirements.
What’s fascinating to me is that in many client organizations in which I’ve worked, there is a single entity in their development methodology known as business requirements and these are the hand-off deliverable that IT is supposed to use to create technology that makes the business partners happy. However, what these business requirements contain is almost never the same across projects within a given organization and is often vastly different across organizations.
Stay tuned for more.