Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.)

share|improve this question
    
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. –  edmastermind29 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. –  Emmad Kareem 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? –  edmastermind29 Feb 21 '12 at 18:45

4 Answers 4

up vote 3 down vote accepted

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).

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

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.

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

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.

share|improve this answer
    
Yes. Thanks, Bernard. –  edmastermind29 Feb 21 '12 at 17:03

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.

share|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. –  edmastermind29 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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.