2

Today a colleague who is studying systems engineering told me that software design constraints and GUI requirements (Exs.: the software shall be develop in three layers: presentation, business and persistence; the GUI shall use an tree object to display the structure) could not be considered system or software requirements.

I´ve looked it to some templates of SRS (Software Requirements Specification). The RUP's templates say that design constraints and GUI requirements are a kind of software requirements. Newer templates of IBM put it out of the Specific Requirements chapter.

Then, should constraints software design be considered software requirements?

Improve this question
2
  • 4
    What difference would it make?
    – Frank Puffer
    Apr 19, 2017 at 20:10
  • 1
    It rather depends who is making the decision. Those sorts of decisions can only be made by developers who are actively involved in writing the solution (i.e. people who understand the overall design and the code). Other external parties can make suggestions, but if those suggestions don't fit with the way the rest of the code and the team is heading, they're neither requirements nor constraints - they end up being something perhaps to discuss in a whiteboard meeting but probably ignore.
    – Ben Cottrell
    Apr 19, 2017 at 20:30

1 Answer 1

Reset to default
6

If you are producing a software requirements specification (SRS), I would expect that both GUI requirements and design constraints would be captured in that document.

In ISO/IEC/IEEE 29148-2011, the outline of the sample SRS says that the section for design constraints is used to "specify constraints on the system design imposed by external standards, regulatory requirements, or project limitations." The section on user interfaces is designed to contain "the logical characteristics of each interface between the software product and its users" and includes "required screen formats" and "page or window layouts" among other things as well as "all the aspects of optimizing the interface with the person who uses, maintains, or provides other support to the system".

If you look at previous iterations of the SRS standards, like IEEE 830-1998, you'll find multiple ways to structure the document. On top of that, many organizations may not produce a software requirements specification document, but keep their requirements in another format.

I wouldn't consider your examples to be examples of good software requirements. Both the statement that "requires" a three-layer design and the one that "requires" a tree object are design decisions.

In my experience, examples of design constraints include the use of a particular programming language or framework (or versions thereof), a specific operating system, or references to a standard reference architecture (and this reference architecture may, for example, levy requirements of three-layer architecture on the application). Examples of user interface requirements tend to require compliance to user interface style guides (for example, requiring a mobile app to conform to either the mobile OS style guide or the company's style guide).

At the end of the day, the requirements should be characteristics that the software must adhere to or it will fail to accomplish the stakeholder needs in the current environment.

Improve this answer
3
  • Not a bad answer, but UI is always a grey area. When a stakeholder writes something like "I would like the UI to display this kind of hierarchical data in a tree-like shape, because <some reason>", this can be a perfectly legitimate requirement.
    – Doc Brown
    Apr 20, 2017 at 11:05
  • @DocBrown I think it depends on who that stakeholder is. If it came from a customer or user, I'd still run it by the business analysts, product owners, UX team, and whoever is implementing the UI to make sure that it's valid. If it is, I still wouldn't capture that as a requirement, but in a design and include a reference to however that idea was generated. If it came from product owners or UX, I'd still not want that captured as a requirement but again in the design.
    – Thomas Owens ♦
    Apr 20, 2017 at 12:21
  • Well, if customers, users, BA, PO, UX team and developers will all raise their hands, expect stackoverflow.com/a/84624/220984 ;-)
    – Doc Brown
    Apr 20, 2017 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.