I am writing an action plan for a personal software project, which I will do research on before and during development. I think the name "action plan" does a decent job describing what it is used for. The research report that will be written after the action plan, will be finished at the same time the application is done. UML diagrams are part of the research, but what about requirements? Is knowing the requirements part of the plan or do you need to have done some decent research before knowing what they are?

Here are headings of my action plan so far, excluding general purpose report headings such as 'Introduction' and the like, to give some context of what, I think, is supposed to be in the plan:

  • Background
  • Scope
  • Problem analysis
  • Goal (research question)
  • Research method
  • Stakeholders (me)
  • Strategy (version control, tools, testing, etc)
  • Risk analysis (time, costs, etc)

I guess the 'Requirements' heading would be inbetween the headings 'Strategy' and 'Risk analysis', but I am not sure if they should be in the report at all.

  • 3
    I think you need to take a step back. Why are you creating so much documentation for a personal project?
    – Thomas Owens
    Feb 19, 2017 at 0:54
  • @ThomasOwens mainly to learn how to write them. If I were to write one for a company with coworkers and more factors, I think the question would still be the same.
    – oddRaven
    Feb 19, 2017 at 9:29
  • 2
    If you were writing a document for a company, I would tell you to either consult your manager or talk to the stakeholders to see what they expect from the document. An "action plan" isn't a standard document in the software development process. There are a number of ISO and IEEE standards that exist around artifacts, but even a company that chooses to follow these standards for content may structure the content across different tools, repositories, or documents. Honestly, if you were a company and you told me that your requirements were in a document - I'd be scared.
    – Thomas Owens
    Feb 19, 2017 at 11:07
  • My school required me to write an action plan, so I assumed it was part of working on a project. What we would do is think of requirements, put them in a spreadsheet and when done copy the table and put them in the action plan. This report would be exported to PDF and then be send to whoever for validation. The requirements would be used to make user stories for scrum, so they would have no real use afterwards. I need a plan and requirements, how do you suggest I work with them instead?
    – oddRaven
    Feb 19, 2017 at 14:45
  • That process is incredibly heavyweight, and I've worked in two regulated industries. If you are doing a project on your own, focus on why you are doing the project and not this. What problem are you actually trying to solve? I think you have an XY problem and need to actually ask about what the problem is. You seem to think that making an action plan that contains certain information is the answer. We can't tell you how to write that document, but I think that trying to create this document isn't solving your problem.
    – Thomas Owens
    Feb 19, 2017 at 17:51

1 Answer 1


You are right to expect a software project to involve requirements. Requirements are step #1 in almost any software project. That being said, there are many kinds of requirements.

For an academic action plan, I would suggest that high level requirements may be helpful-- stating them can help guide your effort and help your advisor advise you. A high level requirement can be as vague as you need to indicate intention but not implementation. Generally they are going to be written from the point of view of the associated line of business, or sometimes from an end user perspective.

Later, you will need to come up with derived requirements or detailed requirements, which will use the high level requirements as a basis. For extra credit you may even offer to put together a traceability matrix which shows how they are tied together-- this ensures completeness and helps identify scope creep. The lower level requirements can include much more technical information that may not be obvious to an outsider, and will help you flesh out the details of what you are going to build and help communicate your ideas to your advisor.

The purpose of a planning document is to be reviewed. So the number one question you should ask yourself is if the reviewers will be interested in the content, and the number two question is whether a review of the document will get you the feedback you need to catch any mistakes and overall to be successful.

Your Answer

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

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