I am a master student and got a project I need to manage from the start to the end (first time). I am the only one working on it.
I just ended the information search phase and now the specifications phase is starting. I need to write two specifications:
Which one should I write first ? It feels like they both rely on each other and so, I am struggling to pick one or the other.
As you noticed, the architectural and a performance specifications are interdependant.
However, in most cases you are going to want the product to be as fast as possible - and therefore you want to deal with the performance fist, and then ensure your proposed architecture can match the performance spec.
In most cases, in order to improve performance you will have to revise the architecture, and every change to the architecture could affect performance, hence you want your performance spec first.
Your question is about an academic exercise where the only "correct" answer is the one your instructor has previously provided, or whatever answer the instructor expects. Instead, I will approach the question from a real-world project management perspective that may help you differentiate the functional and non-functional requirements of your project, and therefore help you sequence them in a less tightly-coupled way.
While your question isn't tagged with agile or one of its many implementation frameworks like scrum, it would be remiss not to point out that straitjacketed projects are rarely agile, and tend to be much more fragile in their implementations. The inability to escape or successfully modify early upfront requirements is one of the many reasons that IAG reported in 2008 that 68% of IT projects fail. Being agile doesn't prevent failure, of course, but it does tend to reduce the overall incidence of complete project failure, and generally reduces the overall costs associated with a given project's failure. I would argue that those are valid reasons not to over-constrain a project with non-functional requirements (of which "performance" is often one such, although that may vary with the given problem domain) to avoid creating the conditions that often lead to such failures.
Even if your particular problem domain requires a certain performance envelope to be successful, overly-constraining the solution space upfront is often a project implementation anti-pattern. In the next section, I explain why performance is (or at least should be) a secondary consideration for many projects.
Systems architecture and engineering are off-topic on Project Management Stack Exchange, but the question is answerable from a project management perspective. While you may get different answers on sites about business analysis, marketing, regulatory compliance, or systems engineering, here you should expect answers related to the practice and profession of project management.
You asked:
I need to write two specifications:
- An architectural specification.
- A performance specification.
This is partly a business analysis question, and partly and engineering/architecture question. From a project management perspective, the only part of the question that is really on topic for a real-world project (rather than a homework assignment) is whether or not your project charter and success criteria require non-functional requirements such as "performance specifications" in order to be closed out successfully. If they are required then they must be considered, but the sequencing is often not as tightly coupled as you appear to think.
As a general rule, the currently-accepted wisdom in most technical domains is:
First make it run, then make it fast.
or alternatively:
- Make it work.
- Make it right.
- Make it fast.
I didn't invent these widely-quoted aphorisms, nor am I sure to whom they should be attributed. However, the YAGNI principle from eXtreme Programming (XP) also applies, as does an XP quote from Ron Jeffries that says:
Always implement things when you actually need them, never when you just foresee that you need them.
All of these phrases basically say the same thing. In most systems and for most purposes, correct operation usually needs to come before performance optimizations. This is especially true if the performance requirements are non-functional requirements that are arbitrary targets that may be difficult or cost-prohibitive to achieve, or requirements that actively get in the way of developing a working system in the first place.
While functional and non-functional requirements are intertwined in the sense that you should discard any architectural or systems-design approach that would be unable to deliver the performance requirements needed for successful delivery of a given product, as a rule of thumb focusing on speed or other performance characteristics before you have a functional design is usually a sign of premature optimization (see aside below).
There is no doubt that the holy grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
— "Structured Programming with go to Statements." Donald E. Knuth. ACM Computing Surveys, Vol. 6, No. 4, Dec. 1974, pp. 261–301.
As always, your project initiation (including stakeholder expectations and project sponsorships) will drive a lot of this conversation. Make sure you differentiate between must-haves and nice-to-haves in your project charter, and that project stakeholders and sponsors have plenty of opportunities throughout the project lifecycle to determine if the product is "good enough" rather than chasing some arbitrary specification baked-in early in the project's lifecycle.
One of the reasons that agile frameworks are often more financially efficient (by which I mean they are often less prone to sunk costs and more likely to "fail early" when necessary) is because big, upfront design often bakes in assumptions that are either incorrect or irrelevant as the project evolves. While there are certainly projects where all variables must be firmly fixed up front, agile frameworks benefit from both emergent design and just-in-time planning that allows YAGNI and continuous re-evaluation of what's really important to successful product delivery to be constantly re-assessed throughout the project.
Unless you're building a pacemaker or a real-time system, projects often discover that a background process that takes 10 minutes once a day is "good enough" even if someone originally asked for a 5μs on-demand process. They may also decide that they'd rather spend development budget on some feature that's more important than raw performance, or that the cost or level of effort to bring the required process down from 6μs to 5μs simply isn't worth it.
The second principle behind the Agile Manifesto says:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Fixing all your requirements up front—especially when it isn't strictly necessary for the given problem domain—limits opportunities to change requirements, increases opportunity costs, and reduces the potential to make changes for competitive advantage.
