While software design is 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, GitHub or another repository management system will enable you to keep track of different components and successfully combine the efforts of many different team members.

A mapping of the stages of project development for a software project in Capstone 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

In this stage, the team works with the sponsor and market (which is likely to be your sponsor) to determine the high-level requirements (“Key Success Measures” in Capstone-speak). Risks are assessed and thought is given to testability. Software “prototypes” are often written to determine feasibility. These requirements are clearly defined and documented in the SRS.

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

The architecture is presented visually, with clear diagrams specifying modules and interfaces. Evidence from software prototypes is presented to demonstrate feasibility of the concept. Videos of working code may be included in the review. A test plan is also included to demonstrate testability of the software components as well as the complete software package, when completed.

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

The software architecture is fully specified. Modularity, budget constraints (both money and time), testability, and robustness are all considered, justified, and documented.

Programming languages are specified based on what is best for the project and what meets the needs of the sponsor to ensure transferability.

Architecture diagrams (block diagrams, UML diagrams, flowcharts, etc) are developed that illustrate your design, and these include clear interfaces between modules. Details of the design are all clearly specified, including data flows with external modules. If your project includes a GUI, wireframe diagrams (software packages like Figma, lnVision, Adobe XO, can make this easy) should be used to provide clear mockups of the GUI design.

A high-level test plan is included demonstrating thought has been given to testability of the software (including automated testing as appropriate).

A formal schedule is presented that includes not only Capstone “milestones” (due dates), but also key development milestones specific to the project that must be met to ensure the development cycle stays on track.

Additions and modifications are made to the SRS as needed.

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

Code is developed according to the design specified in the architecture review. Code is well documented, including in-line comments that explain what is being done in functional blocks of code. Variable names should be helpful in explaining what is happening in the code block.

A Software Bill of Materials lists all software packages used, including version numbers. Documentation for recreating the development environment is maintained.

Project management is mandatory at this stage. Deliverable dates and team member responsibilities are clear and easily accessible by all team members. Dependencies are recognized and tracked. (See Software Resources for tools you might employ to make this easier)

Test plans are written and executed, and results are documented. This may take the form of a Jira board, Github bug reporting, or whatever works best for your team.

SRS is updated appropriately.

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

This stage represents the final aggregation of all components and modules into a single system. The complete software package must be tested again as a system.

Makefiles are used and documented to automate the development environment.

SRS is complete and accurate.

Software Bill of Materials is complete and accurate.

Test plans are specific and address areas of potential failure. In the testing, attempts are made to break the code. For example, if given corrupt input, does your software return an appropriate error message, or does it fail? Automated tests are used where it makes sense to automate.

All details to recreate development environment and run software are included in the final report. Output is clear. Obvious thought has been given to user experience.

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 the Class Documents/Templates folder on Box.
• 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. Jupyter Notebooks can also provide great visual documentation.

Software bill of materials (SBOM from NTIA)

Repository

Software architecture/navigation artifact

Appropriately commented code