Software Engineering – Requirements


Gathering requirements is very important, as they are a way of finding out what the new system should do, as well as make sure that your application supports the appropriate activities.
You are in constant communication with the customer, the users and developers, so that your system will match the users needs.


Failure of Software Projects

There are 10 reasons for a software project to fail, these are:

  1. Incomplete requirements (you should know this by now…)
  2. Lack of user involvement
  3. Lack of resources
  4. Unrealistic expectations
  5. Lack of executive support
  6. Changing requirements and specifications
  7. Lack of planning
  8. Elimination of need for the project
  9. Lack of management
  10. Technology illiteracy


So, when should you gather requirements? The short answer is: ALWAYS! 😀 but most importantly at the beginning, else you’ll have no starting point.

So, why always? because requirements can change! The best way to avoid issues with requirements change is to not use the Waterfall process, but to use the Agile process – so that your users stay close.



Where should you gather requirements from? Well, nearly all requirements are gathered by asking the customers/users questions about what they require the system to do.

Look at the place of work, if they have lots of Post-it notes everywhere, then maybe there is some information on those, or maybe they would like to use the system to replace those post-it notes.

You could also look at the resources that are used in the task.


Refining Requirements

When gathering requirements, there is some structure to it. Such as asking questions, then from that you can make a Requirements Document and a Glossary. From that you can make a Use Case Diagram etc etc:



Kinds of Requirements

According to Ian Somnerville there are many kinds of requirements, these are:

Functional Requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

Non-Functional Requirements: Constraints on the services or functions offered by the systems

Domain Requirements: Requirements that come from the application domain of the system and that reflect characteristics and constraints of that domain

User Requirements: Statements, in a natural language plus diagrams of what services the system is expected to provide and the constraints under which it must operate

System Requirements: Requirements that set out the systems functions, services and operational constraints in detail.


Presenting Requirements

once requirements have been gathered, they must be well presented. This is normally done in the form of a document commonly known as a Requirements Document.

Within it, it is normally split into a number of sections, such as sections for Function, Non-functional and User/Domain requirements.


About Badgerati
Computer Scientist, Games Developer, and DevOps Engineer. Fantasy and Sci-fi book lover, also founder of Cadaeic Studios.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: