Designing and Writing Software - Overview

Organizations or individuals use some version of a software development process to take their ideas about a task that must be performed and turn that into a set of instructions and data that a computer or a set of computers) can execute. not None ext): active_object

4 slides · 2 min read · Domain 8

Slide 1

Ideally, that development process ensures that 100 percent of what the users need from that software is translated into actions (instructions) for the computer to perform.

  • Business and mission needs, modeling languages, graphical techniques, simulations, and narrative techniques aim to capture the total set of requirements for the system.

This translation process often involves many layers, each layer moving further from the mission-oriented "businessspeak" that the users express their needs with, down to the files of binary digits and data values that computer hardware can make use of, and can include:

Many of these approaches are highly informal and unstructured.

  • Requirements modeling and specification languages, processes, and techniques aim to translate the set of mission needs into three broad classes of requirements or properties that the finished system should have:
  • Emerging properties is an alternate and perhaps more powerful way of looking at systems-level behavior characteristics such as safety and security. This perspective also helps provide a more testable, measurable answer to questions such as "how safe is our system?"
  • Functional requirements describe a finite task or process the system must perform. It describes the functions a software must perform. A function is nothing but inputs, its behavior, and outputs. "Release weapon on target after all safeties are disengaged" is a functional requirement.

These are often directly traceable to specific elements in the final system's design and construction; formal configuration item audits should, for example, be able to identify a given unit of software with the specific functional requirements that dictated it be written and included into the product build.

  • Nonfunctional requirements identify broad characteristics of the system as a whole, such as "must issue prescriptions with no more than one error in every 100,000 processed." These usually do not align with a clearly identified subset of systems elements. Typically, many safety, security, privacy, and resiliency needs have been deemed nonfunctional by their systems analysts and engineers, and as such, configuration audits cannot identify whether any given software unit contributes to such nonfunctional requirements, or indeed if any of them do. Another example is how fast does the website load? Failing to meet nonfunctional requirements can result in systems that fail to satisfy user needs.
  • Design languages and tools assist in translating requirements to both the overall systems design, the design of its component subsystems, and to the control flows and processes that embody large, complex sets of user tasks (such as "Examine all bank records for suspicious patterns of transactions suggestive of money laundering activities.").
  • Programming languages provide the first formal ways to translate designs into bits that the computers can execute.

One such design language is pseudocode, which is using the native language of the designers and users to write a somewhat more programming-oriented description of what a task is required to do.

Test this domain