While software is certainly an essential engineering activity, it has characteristics that can make it different than the hardware-focused projects that have been traditionally sponsored in BYU Capstone. Every year more and more projects incorporate more software components or have objectives that are entirely software products.

Because of the ability to rapidly prototype changes and the fact that your prototype can actually become the product, the nature of software projects is more iterative than most hardware design projects and follows the process outlined in Figure 6-3 of Design Decisions more closely than the traditional waterfall project management procedure associated with the Capstone hardware development process. However, because of the fixed schedule and resources allocated to your project, appropriate goal targets combined with agile management are essential to make sure that your efforts are appropriately mapped to achieve a successful outcome.

You should use software to manage software. Appropriate use of GitLab or another repository management system will enable you to keep track of different components and enable you to successfully combine the efforts of many different team members.

A mapping of the stages of project development for a software project may look more like this (1.0 constitutes a major or public release):

Opportunity Development → Software Requirements Specification V 0.8; Software V 0.1

Concept Development → Software Requirements Specification V 1.0; Software backend V 0.3 with GUI V 0.1

Architecture Development → Software Requirements Specification V 1.1; Software backend V 0.5 with GUI V 0.5

Subsystem Engineering → Software Requirements Specification V 1.5; Software backend V 0.9 with GUI V 0.9

System Refinement → Software Requirements Specification V 2.0; Software backend V 1.2 with GUI V 1.2

Throughout the software development process, you will need to show that your product does what it is supposed to do, does not do what it is not supposed to do, and is able to be updated, refined, and deployed by future engineers. In this way, the principles of desirability and deliverability (transferability) apply to these types of projects. Generally, software projects will not produce the diversity of artifacts of hardware projects, but the artifacts they produce will be updated much more frequently as coding progresses. Major artifacts that describe the software product deliverables are the following:

Software Requirements Specification (SRS from Wikipedia)

• Whether or not you use a particular template or form, the key is that you know, your sponsor knows, and Capstone knows what your software product is supposed to do (and not do) when you are finished.
• The requirements should be unambiguous in the sense that a third-party could verify if your design meets/does not meet them.
• This document will go through many versions as you progress through your project.
• An IEEE example of an SRS is available online.
• A Word template for the IEEE SRS is available in theClass Documents/Templates folder on Box. If you create (or are interested in) a LaTeX template, let us know and we will try to make one available.
• An example of a Capstone team's SRS is available in the Class Documents/Examples folder on Box.

Market Response (from market about the desirability of your product)

• Remember that the design team is not the market and so outside feedback is absolutely necessary to judge the success of the design.

Release Notes/Bug Testing Report (showing appropriate code coverage and successful test passing)

• These are critical to evaluate the progress your team is making and also allows future developers to know what needs to be addressed.

User Manual - use something like Sphinx to do this automatically as your code evolves

Software bill of materials (SBOM from NTIA)

Repository

Software architecture/navigation artifact

Appropriately commented code