Description

Respond to Chavez:

I read an article titled What do Software Architects Expect from Requirements Specifications? Results of Initial Explorative Studies. The article documents goals and initial results of three studies on methods used for Software Requirements Specifications (SRS) and the information needs of software architects who use SRS.

Software Requirements Specifications (SRS) are crucial in software development because they provide the documentation containing all of the necessary and official information that is needed to implement a software system (Gross & Doerr, 2012). Software architects base decisions about the system structure on the SRS. Other software development team members, such as usability experts and testers, may also gain knowledge about the system from the SRS.

The article points out some of the problems often faced by SRS “consumers”. First, consumers are provided with SRS that tend to contain more information than is necessary to make the architectural decisions. Second, the level of detail of the information represented in the SRS is in effective or not appropriate. Lastly, it has been noticed that crucial information is often omitted from the SRS.

In order to solve these problems, the researchers conduct view-based studies that present SRS using a Task-Oriented Requirements Engineering (TORE) Framework to different groups. This framework offers a way to present specific requirements while remaining in the context of information systems development (Gross & Doerr, 2012). The information is represented as “Artifacts”, such as persona descriptions of stakeholders or UML activity diagrams, that document the system requirements. The artifacts can further be classified into artifact types like descriptions of stakeholders, descriptions of business processes, descriptions of goals and other useful types.

Based on the TORE framework, artifacts are presented based on decisions made on three levels of abstraction:

  1. Goal and Task level – These are decisions made regarding the stakeholders that the system supports and their goals that must be fulfilled by the system. It also includes tasks that use these goals.
  2. Domain level – This level analyzes and refines tasks from the previous level. The decisions made in the domain level are known as “as-is activities”, “as-is workflows”, “to-be activities” and “to-be workflows”. Decisions will also cover the future task execution of the system and the data necessary for the execution of tasks.
  3. Interaction level – Here, system-supported activities are refined and specified and decisions have to do with system functionalities, how actors interact with the system, data exchanged during interaction and logical grouping of system functionalities into workspaces (Gross & Doerr, 2012).

Results from the studies helped show an initial understanding of what information should be part of an SRS based on the viewpoint of software architects. According to Gross & Doerr, the main studies produced the following findings:

  • Descriptions of system functions and interactions were very important artifact types.
  • Artifact types documenting information about system responsibilities, data, system functionalities, interactions, technical constraints and stakeholder goals are important for software architects.
  • Software architects preferred artifacts with notations that contain structured text or graphical representations.

I found the article to interesting because it emphasizes how a poorly written Software Requirements Specifications can affect decisions made by those who rely on the information contained or missing from the SRS. System documentation, like SRSs, should contain detailed information that is needed by its intended audience. It should not omit crucial system details or contain more information than is actually needed. Furthermore, the content should be presented in an understandable way that allows for better decision making. As we have all learned in our studies or technical roles, there is no room for bad decision making in the software development lifecycle.

References.

Gross, A., Doerr, J. (2012). What Do Software Architects Expect From Requirements Specifications? Results of Initial Explorative Studies. [Paper presentation]. 2012 IEEE First International Workshop on the Twin Peaks of Requirements and Architecture (Twin Peaks), Chicago, IL, United States. https://www-computer-org.ezproxy.umgc.edu/csdl/proceedings-article/twinpeaks/2012/06344560/12OmNyFCw2B