Learning Outcomes Achieved

1. Identify and apply appropriate software engineering and project management methodologies, tools and techniques for the development of solutions to real-world problems
2. Explore the implications of computer and network architectures for system-level design and development, as appropriate for risk and quality management

Volere Requirements

The unit reading and seminar preparation required that students read about the Volere requirements (Volere, n.d.). They piqued my interest because they appear to solve a problem I’ve frequently encountered in software engineering: obtaining clear requirements. The latest version of the requirements are free for academic use, so I sent an email to the writers requesting a copy and I read through it.

What I liked about Volere rqeuirements is that their philosophy relies on the concept of testing requirements as soon as they are received- in other words, when you receive a requirement, you need to be able to answer the question: “How can we verify that we’ve built the right thing?”. The answer to this question is referred to as the “fit criterion” in the specification document, and if a fit criterion cannot be defined, then the requirement must be clarified and re-evaluated (spelling correct?). All requirements, in the Volere framework, must have a fit criterion.

I also liked the “snow cards”- they are simple, but provide valuable information on requirements in a clear and easy to understand way. However, I felt that the “snow card” tries to do too much, consequently, some of the information is either unnecessary or should be discussed outside of the card- this includes priority, requirement types, and customer satisfaction/dissatisfaction (an arbitrary scale of 1-5 isn’t clear or informative). My personal thoughts are that the sections which matter are:

• Description
• Rationale
• Originator
• Fit Criterion
• Dependencies
• Conflicts
• References to events and use cases which need the requirement implemented

Having come to this understanding, I think the best way of applying it is not necessarily building a card for each requirement with all of these fields (unless you’re working on a large-scale project). Rather, it’s fundamentally more important to have an awareness of these aspects when discussing a requirement in any project management scenario. I will use this knowledge for the project report assignment, by discussing these aspects of the requirements which we’ve received from the other team- I don’t think we would have the time to create actual snow cards.

In completing this reading and reflection, I have achieved learning outcome 1, because I have learned a new method for requirements gathering- a method that adds more structure to the process and guarantees testability of requirements due to its nature.

References

Volere (n.d.) Volere Requirements Specification Template. Available from: https://www.volere.org/templates/volere-requirements-specification-template/ [Accessed 14 March 2022].

Seminar 2

This week, a seminar was held. Some time during the seminar was dedicated to discussing low-level computing topics, such as Flynn’s taxonomy. During the seminar, there was a question about the relevance of such topics to project management, in response, I argued that fundamental computer science topics can still be relevant during project management discussions; as an example I mentioned IEEE 754 standard, which essentially shows that computers have problems representing decimal numbers. This is something that cannot be completely escaped, meaning that it does need some discussion at a higher level.

I also created a presentation for the seminar where I discussed which data structures I would use to solve a problem, and I have attached those slides to this document. By participating in the seminar through discussing topics and presenting my own slides, I have achieved learning outcome 2 because I learned more about how computing architecture influences the way development problems need to be approached (e.g., developers may need to think about how to parallelise behaviours when efficiency is a requirement). I also achieved this learning outcome through the case study I selected for my slides- the selected use case had various constraints, and limitations of computers began to manifest in the requirements as a result.

Artifacts

Seminar Slides
Meeting Minutes