How to properly manage requirements? RRS feed

  • Question

  • Hi guys,

    I'm having a bit of a hard time managing the requirements for the application I'm currently working on. I'm currently using a product called Enterprise Architect from Sparx (http://www.sparxsystems.com.au/) to manage the requirements and do the general design.

    What I did so far was to collect and filter all requirements and categorize them. For example, there are requirements pertaining to the message list, task manager, connection manager, GUI, etc.

    The problem I'm currently having is twofold.

    First, I'm working alone on this project and I find it extremely hard to keep a clear vision of the project given the tons of requirements already present. Even with my categorization of the requirements, I often lose focus and forget things.

    Second, some of the requirements overlap several categories. As an abstract example, folders have an assigned priority. So, all tasks performed from a particular folder may have an higher priority than any other currently running tasks and should be run immediately and other tasks with a lower priority put to sleep.

    The requirements surrounding the priority in the folders are either replicated or linked to the priority requirements in the task manager.

    I suspect that these questions are pretty common amongst newbie and self-taught designers. I would greatly appreciate any pointers you guys might have regarding these issues.

    Thanks a lot,

    Sunday, May 28, 2006 11:25 PM

All replies

  • Hi,

    Although I have not yet reached the level to do things you are currently doing, I would, however, refer you to a couple of books that I thought would help you...


    Monday, May 29, 2006 3:43 AM
  • Hello Badri, thanks for your reply.

    I will look over the books you suggested. One thing that I found in my readings is that many books are targetting teams and not the one or two person Micro-ISV.

    Thanks again,


    Monday, May 29, 2006 3:50 AM
  • Hello Efortier,

    You are right that this is not exactly an unsual problem, but on the other hand there are not a lot of easy answers.

    Two pieces of general advice I would give.

    1. Yes this is hard. Deal with it. This is actualyl what you do, this is why one needs a human being rather than a computer to do this. Don't allow youreself to be taken over by all the lists and sublists and mechanics of folders etc. Rather, try to understand all teh requirements and see how they all fit together.. basically you need to put it all in your head at one time. After you do that, you may be able to recategorise or sort out the requirements from one another. One of teh biggest things you need to do is differentiate little rats and mice fixes from big feature improvements. The big feature improvements need to form part of a grand 'vision' that you (yes, you) will need to come up with. The little rats and mice - the best thing to do is figure out a new sensible way to categorise them, give them priorties and just try to get through them slowly, marking them off the list as you do them. Don't mix in the big feature improvements or vague requests with the rats and mice as it will only confuse you. Bear in mind that, of course, many times a little fix woudl be irrelevant given a major improvement, so you need to have at least some idea of the higher level road map before you can make sense of the rats and mice. Sometimes its worth fixing a 'rats and mice' for temporary allievation of pain whilst you wait for the big feature.. sometimes not.

    2. Come at this from the other direction, or should I say, other direction(s). Start at the very top and think about your really top business priorities. Maybe the first level is just really basic stuff like 'increase sales', 'reduce costs'.. after that you need to start getting creative and think about ways to actually really do that.. for instance.. to 'increase sales' you may need to improve perceptions of the product in the wider market - that might mean an image revamp - so then.. what sub-projects would fit into that. Alternatively, maybe you have a lot of 'usabilty' complaints and think it makes sense to have a bit of a 'usability improvement drive'. If so, you might want to freese new feature requests that 'add' features and concentrate on just testing the product against real users and figuring out ways to make it easier to use. I have no idea what area you are in so this all pretty speculative. In any event it can be really helpful to kind of categorise things at this 'airy fairy' level so that what you do will have the most benefit to the real bottom line. Another 'direction' you may want to come at it from is in terms of a technical architecure timeline. This always needs to be in the passenger seat to the real drivers of what you are tring to achieve, but it can be helpful to categorise things in terms of major architecture shifts - for example the new rendering pipeline enables this and that.. or a new api layer would enable this other thing. Figure out how to tie together the higher level goals with the timeline and try to think at the larger 'block level' for a while to come up with the basic roadmap. It doesnt have to be perfect and you may need to change it (in fact you will) but the important thing is to have some sort of general roadmap. Like I say, I dunno what specic area you are in, but the general idea here is that if you are getting lost in all the little details it might be helpful to come up with some wider/higher level goals and then fit the feature requests into that, instead of trying to find the 'right' way to categorise and group nad combine all the feature requests that are actually there. The priorities that fall out of this process may, in fact, suprise you.

    Anyway good luck with the job. Maybe you are actually lucky to be challenged with something that is 'hard' and that requires your thought and consideration to make sense of it, as it gives you a reason to be doing what you are doing. Personally I find that a few quick whiteboard 'brain dumps' and mind maps can help me make sense of things, as well as, of course, sleeping on it, and having it all come clear whilst standing in the shower the next morning ;-).


    Thursday, June 1, 2006 3:32 AM
  • Hi Miles,

    I think you are right in that I tend to focus on every single details, big or small, and end up getting lost in them.

    Today I've been trying to focus on the larger parts and things seemed to make more sense. I'll continue that way and see how it goes.

    It's still pretty hard for a single person -for me at least- to manage an app with thousands of requirements. I guess that's the nature of the beast.


    Thursday, June 1, 2006 9:52 PM
  • Where I work we usually use Requirement management tools (Requisite pro, Doors etc.) and develop elaborate use case models (both diagrams and written use-cases) - however we usually work on large project which involve multiple teams (and disciplines)

    Since you mentioned you only have few developers and that elaborating the requirements makes it hard to see the trees for the forest. You may want to look at agile development methodologies such as SCRUM. http://www.controlchaos.com/


    SCRUM is a good project management process (it is also scalable to larger teams) -There are several areas that SCRUM covers -  In regard to requirements you would basically maintain a list of (high-level) requirements/feature (product backlog) of which you would choose (along with the product owner) a subset for each iteration (a 30 days "sprint" in SCRUM speak). The sprint requirements list (sprint backlog) will be elaborated further (e.g. to user stories http://www.extremeprogramming.org/rules/userstories.html). The advantage here you will not try to encompass all the requirements and get yourself bogged down in endless details - instead you would be more busy creating working software that satisfies the high-priority areas of your product.



    Friday, June 2, 2006 7:57 PM