Software Development Process 4 | Requirement Engineering and Java Programming

Series: Software Development Process

Software Development Process 4 | Requirement Engineering and Java Programming

  1. Requirement Engineering (RE)

(1) The Definition of Requirement Engineering (RE)

Requirements engineering (RE) is the process of establishing the services that the customer requires from the software system. In addition to that, requirements engineering also has to do with the constraints under which the system operates and is developed.

There are reasons why the requirement engineering is very important,

  • Many errors are made in requirement specifications
  • Not detect these errors can dramatically increase software costs

(2) The Definition of Software Requirements Specification (SRS)

The final result of the requirements engineering process is a software requirements specification (SRS). This answers the question on,

  • what the proposed system is intended to do

Instead of,

  • how the system does it: this is a result of the design of the system

(3) The Definition of Software

Software is an abstract description of a set of computations that becomes concrete and useful only when we run the software on some hardware in the context of some human activity that it can support. When we say software, what we really mean is a software-intensive system. It's the combination of 3 things,

  • The software
  • The hardware on which the software runs
  • The context in which the software is used

We usually take hardware and context for granted, but they actually need to be explicitly considered when building a system. Otherwise, we might forget this is all the functionality, and ultimately of the requirements and we might end up with the wrong system.

(4) The Definition of Software Quality

Software quality is not just a function of the software. Instead, it is a function of both the software and its purpose. So a software system can be of low quality not only because it does not work well, but also for it does not fulfill its purpose. We can therefore define the quality of software in terms of fitness for purpose.

Identifying the purpose of the software is exactly the goal of requirements engineering, and it is the reason why requirements engineering is such a fundamental activity in the context of software engineering.

(5) Difficulties of Requirement Engineering

In fact, identifying the purpose or defining the requirements of a system is an extremely hard task. It is hard because，

  • Sheer Complexity: the purpose of most systems is inherently and extreme complex
  • Subtle Human Purpose: it is very hard to extract from humans this purpose and make it explicit
  • Unstable Requirements: requirements often change over time
  • Stakeholders Issues: stakeholders often have conflicting goals and requirements

(6) The Definition of Completeness

One bad result from these requirement engineering difficulties is the lack of completeness. Completeness refers to the fact that it is often extremely difficult to identify all of the requirements. Therefore, it is very difficult to have a complete picture of the purpose of the software.

(7) The Definition of Pertinence

Another result has to do with the lack of pertinence. Pertinence conversely has to do with the relevance of the requirements. To avoid completeness problems developers often end up collecting a lot of irrelevant when not conflicting requirements. And to make things even worse, collecting all of these requirements sometimes doesn't even solve the completeness issue. There are some possible harms for the irrelevant requirements,

  • they can introduce inconsistencies
  • they can waste development resources

(8) The Bottom Line of Requirement Engineering

Based on our discussion, the bottom line is that gathering an adequate, accurate, complete, and pertinent set of requirements that identify the purpose of a software system is an arduous task.

(9) Best Practice for Requirement Engineering

In practice, developers or analysts usually identify a whole bunch of requirements, sometimes the easiest and most obvious ones. They bring those to the stakeholders, and the stakeholders have to read the requirements, understand them, and if they agree, sign off on them.

However, the problem is that these requirements documents are difficult in general because they are

  • long
  • unstructured
  • full of information
  • unpleasant to read

So what happens is that often the stakeholders are short on time and overwhelmed by the amount of information they’re given, and so they give in to the pressure and sign. This is a bit of a dramatization but it's clear that what we are looking at is not an ideal scenario.

(10) Another Definition of Requirement Engineering

Before we see how we can form a rigorous and effective requirements engineering process, let’s first see another definition of requirement engineering.

Requirement engineering is a set of activities concerned with identifying and communicating the purpose of a software-intensive system and the context in which it will be used. Hence, requirement engineering acts as the bridge between the real-world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software technologies.

Now let’s analyze this definition,

  • RE is a set of activities rather than a phase or a stage
  • Communication is as important as analysis
  • Quality means fitness-for-purpose
  • Designers should now the context (where and how) of the system
  • Requirements are partly about what is needed, and partly about what is possible
  • Constituencies mean that we should identify all the stakeholders — not just the customers and the users

(11) The Definition of Requirement

At this point, we have talked quite a lot about the requirement, but what is a requirement actually? To define that we’ll use the following diagram which is a classical one,

At a higher level, this diagram contains two main parts,

  • The Domain of the Machine: the hardware, operating system, libraries, and so on, on which the software will run (normally no direct application in the real world)
  • The Domain of the Application: a world in which the software will operate (normally a concrete purpose of the real world without any plan)

At a lower level,

  • The machine domain is characterized by computers (i.e. C), which are the hardware devices, and the programs (i.e. P), which are the software running on these devices
  • The application domain is characterized by domain properties (i.e. D), which are the things that are true of the world anyway whether I am building my system or not, and the requirements (i.e. R), which are things in the world we would like to achieve by delivering the system that we are building

At the intersection of the application domain and the machine, the domain is what we normally call the specification (i.e. S), which is often a formal description of what the system that we are building should do to meet the requirements.

(12) Two Kinds of Shared Phenomena

As the diagram shows, the specification is written in terms of shared phenomena, which are the things in both the machine domain and the application domain. And we can think about two main kinds of phenomena,

  • Phenomena I: events in the real world that the machine can directly sense. These are events happening in the application domain, but the machine can detect them.
  • Phenomena II: actions in the real world that the machine can directly cause. This is something that the machine can make happen and then can have a manifestation in the real world by application domain.

(13) Functional Requirements Vs. Non-Functional Requirements

Among the requirement that we can collect from the application domain, we need to distinguish between two main types, functional requirements and non-functional requirements.

  • Functional Requirements: have to do with the functionality of the system. In general, these kinds of requirements have well-defined satisfaction criteria.
  • Non-Functional Requirements: refer to a system’s non-functional properties or systems qualities such as security, accuracy, performance, cost — or usability, adaptability, interoperability, reusability, and so on. Unlike functional requirements, non-functional requirements do not always have clear satisfaction criteria. Therefore, we need to refine these requirements so that they become verifiable.

(14) User Requirements Vs. System Requirements

Another important distinction, when talking about requirements, is that between user and system requirements.

  • User Requirements: requirements that are written for the customers and stakeholders, and are often in natural language, and don’t contain technical details. It’s a way for the analyst, the developers, to communicate with the customers, with the stakeholders.
  • System Requirements: written for developers and contain detailed functional and non-functional requirements which are clearly and more rigorously specified than the user requirements. They must contain enough details so the developers can take them and use them to design and then develop a system.

(15) Requirement Origins & Sources

Now, let’s discuss where do requirements actually come from? There are three main origins,

  • Stakeholders: anybody who is affected by the system and its functionality (e.g. customers, users, and so on).
  • Application Domain: where should we use this software? What are the constraints and regulations (e.g. banking regulations, school regulations, etc.)?
  • Documentations: everything else that refers to the functionality of the system we are going to build (e.g. notes, papers, manuals, books, and so on).

(16) Requirement Elicitation Problems

However, extracting requirements from these sources is not a straightforward task. There are many issues involved with the requirements elicitation,

  • Thin spread of domain knowledge: knowledge is vague, distributed, and rarely written down. There are often conflicts between the knowledge gathered from different sources.
  • Say-do problem: knowledge is often tacit. Even if the knowledge were more concentrated, people simply find it hard to describe knowledge that they regularly use.
  • Limited observability: the problem owners might be too busy to perform the task that we need to observe, or they might be doing a lot of other things together with the task that we need to observe so that it becomes confusing. In addition, the presence of an observer might change their problem. It is very typical for human subjects to improve or modify an aspect of their behavior, which is being experimentally measured in response to the fact that they know that they’re being studied.
  • Biased Information: the information that we collect might be biased for several reasons. In all the common cases in which the outcome might affect them, people might provide you a different picture from the real one in order to influence you. They might have a hidden agenda, and mislead you, either consciously or unconsciously.

(17) Traditional Techniques for Requirement Elicitation

Here are some traditional techniques for requirement elicitation that can be used separately or combined,

  • Background Reading: reading existing documents such as company reports, organizational charts, policy manuals, job descriptions, documentation of existing systems, and so on.
  • Hard Data and Samples: viewing hard data includes facts and figures such as forms, invoices, financial information, server results, marketing data, and so on.
  • Interviews: interviews can be structured or open-ended based on the purpose. On the positive side, interviews can rich knowledge in depth. On the negative side, an interview requires experience and expertise. If this information is hard to analyze or even irrelevant, it might become useless.
  • Surveys: quickly collect information from a large number of people onsite or remotely. However, surveys tend to severely constrain the information that the user can provide and might miss opportunities to collect unforeseen, relevant information.
  • Meetings: summarization of findings and collection of feedback. It is fundamental that they have clearly stated objectives and are planned carefully. This is something that should be quite obvious but doesn’t always happen in practice.

(18) Other Techniques for Requirement Elicitation

Besides, there are some other techniques that can be divided mainly into three groups,

  • Collaborative Techniques: like brainstorming
  • Social Approaches: like ethnographic techniques
  • Cognitive Techniques: leverage cognitive science approaches to discover expert knowledge

(19) Modeling Requirements

Once we collected the required knowledge on the requirements for the system that we’re developing, we need to model it in a structured and clear way. More specifically, when modeling requirements, you need to decide what you want to model and how you want to model it. There are really tons of ways to do this depending on your focus and objectives, and the very first one for you to choose is what to model. Basically, we have the following options,

  • Emphasis on characteristics of the enterprise: model goals and objectives of the company, or its organizational structure, its task and dependencies, and so on.
  • Emphasis on information and behaviors: concentrate on aspects such as the structure of information, various behavioral views, or maybe the time, or sequencing requirements.
  • Emphasis on quality of the system: focus on the various non-functional properties of the software that are relevant in the context considered (e.g. reliability, robustness, security, and so on).

After deciding what to model in our system, we have to decide how we want to model it. Whether modeling enterprises, information, or quality aspects there are many possible models that we can use to represent it and all these models have advantages and disadvantages, different levels of formality, and different focuses. In this series, we will only focus on expressing the requirements in the following two ways,

  • Using natural language: informal specifications
  • Using UML diagrams: graphic models

There is also another well-known model called the goal model. The main idea with the goal model is it starts with the main goal of the system and then keeps refining it by decomposing it into sub-goals.

(20) Analyzing Requirements

After having collected and modeled our requirements, we are at the point in which we would like to analyze the requirements to identify the possible problems. Specifically, there are three types of analysis that we can perform,

  • Verification: in requirements verification, developers will study the requirements to check whether they’re correct, complete, pertinent, consistent, unambiguous, testable, and so on.
  • Validation: check whether the collected requirements define the system that the stakeholders really want. Stakeholders may check the requirements directly or interact with a prototype. Surveys, testing, and other techniques can also be used to validate requirements.
  • Risk Analysis: identify and analyze the main risks involved with the development of the system being considered. We may change the requirements if some requirements are deemed to be too risky to eliminate or address these risks.

(21) Requirements Prioritization

While collecting, modeling, and analyzing requirements we might realize that the resources (e.g. time, money, manpower) available for the project are not enough to satisfy all of them. Therefore, we need to prioritize them, and this can be done by classifying them in one of the following three classes,

  • Mandatory: they are must-do things
  • Nice to have: satisfy them if resources allow
  • Superfluous: maybe in the next release

(22) Interactive Process of Requirement Engineering

Basically, a requirement engineering consists of three main steps,

  • Elicitation: extract requirements from various sources
  • Modeling: represent the requirements using one or more notations or formal reasons
  • Analysis: identify possible issues with our requirements

But there is actually a 4th step that we kind of mention but not explicitly,

  • Negotiation: this can happen between the stakeholders and the developers during which requirements are discussed and modified until an agreement is reached

In practice, we continue to iterate over these four steps gathering a better and better understanding of the requirements.

(23) Software Requirement Specification (SRS) Document

Software Requirement Specification document is an important fundamental way to communicate requirements to others. They represent a common ground between analysts and stakeholders because different projects might require different software requirement specifications. So we need to know our context.

In order to have a common format for the SRS document, IEEE defined a standard that divides the document into predefined sections. This is called the IEEE SRS format. It should include the following three main sections,

  • An introduction: purpose, context, and objectives of the project
  • A user requirement definition: user requirements
  • A system requirement specification: functional and non-functional requirements

2. Basic Java Coding and JUnit Assignment

(1) GitHub CLI Authorization

We have done this in the last section. If you haven’t finished it yet, it’s okay to follow the steps. Use GitHub CLI to authorize git,

$ gh auth login

Choose,

  • What account do you want to log into? GitHub Enterprise Server
  • GHE hostname: github.gatech.edu
  • How would you like to authenticate? Login with a web browser

(2) Build the Environment

Go to your local workspace. Clone the latest version of the remote repository, then go to the root directory in the local repo.

$ git clone https://github.gatech.edu/gt-omscs-se-2021fall/6300Fall21<GT username>.git
$ cd 6300Fall21<GT username>

Download assignment3.tar.gz from this link, and then extract this archive in the root directory of the local repo.

$ tar -xf assignment3.tar.gz

this will create a directory called Assignment3 and several subdirectories. Thereafter, we will refer to the directory Assignment3 in your local repo as <dir>.

  • Directory <dir>/src contains, in a suitable directory, the Java interface edu.gatech.seclass.MyStringInterface. It also contains an exception class edu.gatech.seclass.MyIndexOutOfBoundsException, which is used by the interface.
$ ls Assignment3/src/edu/gatech/seclass/
MyIndexOutOfBoundsException.java MyStringInterface.java
  • Directory <dir>/test contains, in a suitable directory, a template JUnit test class edu.gatech.seclass.MyStringTest.
$ ls Assignment3/test/edu/gatech/seclass/
MyStringTest.java

Push an initial version of Assignment3 to the remote repo. Note that you may need to force add the jar files because they are typically excluded by .gitignore file,

$ git add -f .
$ git commit -m "Initialize Assignment3"
$ git push

Then, we should open the Assignment3 directory as a project in IntelliJ to edit the code.

(3) implements Keyword

The implements keyword should be used in the Java class MyString for indicating the relationship to the interface.

(4) Edit JUnit Tests

  • Test for cases
assertEquals(<value>, <called function>);
  • Test for exceptions
@Test(expected = <exception class name>.class

Make sure to submit only the test cases in the template and do not add extra tests.

(5) Run JUnit Tests

Right-click on the name tag for the testing file, and then select Run 'MyStringTest' . If all the test pass locally, we are expected to see,

(6) Submission

To submit our solution, we should,

  • Retrieve the commit ID by
$ git log -1
commit ...

and the commit ID is the long hexadecimal number after commit.

  • Create a file named submission.txt . The first line in this file should be your github username, and the second line should be the commit ID for your submission.
  • Submit this assignment to Gradescope.

Note that we may have to use $ git add -f lib/* for pushing .jar files.