Which process should field specification fall under, requirements or design?

Question

In SWEBOK version 3, there are separate processes defined for requirements and design: "Software Requirements" and "Software Design." Under "Software Requirements" there is a section called "Software Requirements Specification."

Since defining fields of the different object of a new model (e.g. set of classes) is such a common part of building a new project, I expected an example perhaps of that, but none was given from what I can tell.

When it comes to requirements gathering and building a requirements specification, should it include low-level details such as fields and their validation? Or is that typically done in the design phase?

Answer 1

Software requirements addresses requirements imposed upon the system externally and internally from the organization. As such, the requirements will need to specify the data elements that make up external interfaces, or arise from internal work flows, processes and data handling. Those data elements need to be grouped and aggregated according to the needs of the requirements specification process.

For instance, if there is a requirement that a mailing address be validated against an external validation service, such as provided by the postal service in your country, that clearly implies a lot of detailed specification of addresses and how they are organized. Data aggregation, grouping and relationships need to be part of the requirements in order to properly describe what the requirements are asking for.

On the other hand, the design will turn the data elements and groupings into fields, records, classes, forms and tables, and specify the methods by which they are collected, validated, correlated and aggregated.

Answer 2

It's important to recognize that the Guide to the SWEBOK does not define processes. SWEBOK is the Software Engineering Body of Knowledge - it's the collection of stuff that is relevant to practitioners of software engineering. The Guide to the SWEBOK is designed to organize the knowledge into logical categories so that specific topics and associated references and resources can be collected and collated for easy access.

Because neither the SWEBOK nor the Guide to the SWEBOK are processes, neither will provide any guidance for how to do things. Two sections are related to how work is done - Software Engineering Process and Software Engineering Models and Methods. Some of the references in the Software Requirements and Software Design sections will also give suggestions on how to perform requirements engineering or design activities in the context of software engineering projects.

From a broader perspective, there's also a lot of fuzziness in different aspects of the software development process. For example, one method of eliciting and validating requirements is prototyping and this is discussed in the Software Requirements section of the Guide to the SWEBOK. However, prototypes are also associated with the user interface design as well as analyzing and evaluating the quality of a design - both of these are discussed in the Software Design section of the Guide. Prototyping is related to both requirements and design, and I'm sure there are other techniques that cross two or more Knowledge Areas.

If you are trying to define your process, don't look to the Guide to the SWEBOK to help you do that. That's not the purpose of the document.

---

As far as your core question:

When it comes to requirements gathering and building a requirements specification, should it include low-level details such as fields and their validation? Or is that typically done in the design phase?

Like most things in software engineering - it depends.

We've learned that, in many cases, having silos around the different activities and throwing work over the wall doesn't work. In fact, even Winston Royce in the paper that defined a waterfall method called out the fact that the staged progression of a software project was inviting failure and, in order to be successful, one would need to have feedback loops between the different activities.

Your requirements will inform your design. But as you are designing, you may learn more about the requirements. And if you are following an iterative and incremental delivery model, each increment will allow for feedback on both the requirements as well as their realization in the design, which may identify changes to one or both as knowledge increases.