I was recently hired to redesign a management system from scratch. This is my first business-scale project. I have assisted with business applications in the past, but I am the only one dedicated to redesigning and programming the system with the assistance of a company employee. This employee built the previous version of the management system.

We all agree that we want this done, and done right. I am willing to put in the time upfront to define the problem and requirements so I do not have to reap bad seeds during testing.

At the moment, I am trying to capture the problem and gather the requirements for this management system. What questions should I ask this employee to be able to move forward with some documentation? I realize these requirements can change constantly, but I would like a starting point to work with.

Here are a few questions I have come up with:

What is the purpose of the management system?
What is the problem we are trying to solve?
What will be the features of this system?
Who will be using the system? (Employees? Outside Entities?)
What are the means of security for this system? (Can an outside entity see what an employee can see? etc.)

  • Some of those feel general and high level What is the problem we are trying to solve? and others feel granular What are the means of security for this system? (Can an outside entity see what an employee can see? etc.) Start small and scale upwards. Focus on the highest level features that are needed and iterate forward. Trying to nail down everything up front will be difficult and is more often than not a waste of time. – Aaron McIver Feb 21 '12 at 16:48
  • 3
    Do you know what a user story is? Why aren't you capturing user stories? en.wikipedia.org/wiki/User_story. They seem to be a more productive use of everyone's time. – S.Lott Feb 21 '12 at 16:50
  • Thanks, Aaron. I created those questions as a starting point. Good advice. S.Lott, I would accept your comment if it were an answer. Here I am thinking about putting together a requirements document when I can just use user stories. I will do just that. – user48179 Feb 21 '12 at 17:01
  • I would like to suggest, and please don't be angry, that you take few days to browse a book on requirements analysis, structured systems analysis, OO systems analysis and the likes. – NoChance Feb 21 '12 at 18:14
  • Not angry at all. Reason I'm asking is because I need direction and suggestions. Thanks, Emmad. Do you have any recommendations regarding such? – user48179 Feb 21 '12 at 18:45

Questions like this

What is the purpose of the management system? What will be the features of this system?

Are too abstract. They're very difficult to answer, even for IT professionals.

Questions like this

What are the means of security for this system? (Can an outside entity see what an employee can see? etc.)

Are too technical. They're very difficult to answer, and should be left only to IT professionals.

Questions like this are practical and simple.

Who will be using the system? (Employees? Outside Entities?)

What is the problem we are trying to solve?

You'll find that this is the essence of user stories. http://en.wikipedia.org/wiki/User_story

Stick to practical, simple, focused things that users actually know. Avoid the big picture (it's too abstract). Avoid implementation details (it's too technical).

|improve this answer|||||
  • Thanks. This gives me discernment between simple and practical and complex and abstract. – user48179 Feb 21 '12 at 21:16

Ask the employee that built the system about what challenges they were faced with when designing and building the system. You may very well face the same challenges, so you might as well learn something from their experience.

|improve this answer|||||

Since this is a rewrite the first thing you need to establish is why is this being rewritten. from there you can build with more questions depending on the reason why it's being rewritten. Most of the questions you listed should already be answered in existing documentation or as part of why they want a new system.

If it's being rewritten because support for the language no longer exists or the source code is unmaintainable. in cases like this the major requirement is usually that its hard/impossible to tell that it is a different program from the end user perspective.

If the system is being rewritten because it no longer meets the needs of the business then, you are going to have a different set of questions to determine what parts need adding/fixing.

|improve this answer|||||
  • The only "documentation" that exists lies in the head of the employee who wrote this system. I am trying to get this information from him so that I can have something stated on paper. This is being rewritten because the company continued to run into problems as they continued to build onto the code. – user48179 Feb 21 '12 at 17:05
  • You definitely need to produce written documentation. Extract as much information as you can from this person. – Bernard Feb 21 '12 at 17:11

As I have stated in my comment, requirements analysis and capturing has a wide scope. Many books are out there. The real problem, is that there is no agreed upon way to get it right for all projects. There are at least 2 major approaches, the water-fall method and the agile method. You got to pick one.

Here are 2 examples of books that you may want to consider:

  • Requirements Analysis: From Business Views to Architecture

  • Getting It Right: Business Requirement Analysis Tools and Techniques

During requirements analysis, you tend to use tools (not necessarily software packages) such as UML, Data Flow, Prototyping tools for front end design and such. I suggest you use UML if you are building an OO application. For UML, you need to know Class Diagrams and Use Case at a minimum. Whatever the tools and methods you use make sure you describe in your language the details. Diagrams alone are not always enough. Not all users like them and so they can't verify them.

It is important that you understand why the current system is not working, what it is good at and what it can't do. It is important to consider what is the customer expectation about migration of current data.

To be successful, make sure you structure your project plan around real tangible milestones/sub-projects. For example:

Project Step A - Requirements Analysis

A1- Current system analysis

A2- Capturing new system's requirements

A3- Analyzing external systems interfaces (may also be part of A1, A2)

A4- Identifying Data Gaps and Migration Needs

A5- Procedural requirements and data requirements for New system

A6- Release and sign-off final requirements documentation and models

Project Step B - Application Design

Bn- Application interface prototyping (some times this is included in the original requirements...)

Project Steps C,D,... - Other activities

The most important step is to ensure that the project scope is very well defined and to make your customer agree on the fact that the scope will not keep on changing during the project. It is also vital to know that requirements gathering is not about documentation or customer signing, it is about really understanding the business.

I hope this helps.

|improve this answer|||||
  • Excellent post. This gives me insight on what I should expect and what I need to focus on. Thank you. – user48179 Feb 21 '12 at 21:14
  • Thank you very much for your comment. Good luck with your project. – NoChance Feb 21 '12 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy