Are the functional requirements of the existing SW reasonable?

Gathering Requirements is a big joke.

Note: We will devote this part to Functional Requirements. We will have a set of questions related to non-functional requirements later.

Currently Known:

Functional requirements are the primary way customers communicate their requirements to the project team (First). Applicable (functional) requirements help to keep the project team going in the right direction (Second). Unclear requirements lead to a poorly defined scope that creates many challenges from the beginning of the project (Third).

In requirements engineering (Fourth), requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders (First). The procedure is also sometimes referred to as "requirement gathering." (Will be discussed in the current Definition of Functional Requirements and Solicitation Process following questions.)

Reference: Requirements Engineering A good practice guide, Ramos Rowel and Kurts Alfeche, John Wiley and Sons, 1997

Explanation:

First:

(1) "A customer communicates their requirements to the project team" Based on my experience and research for more than 40+ years as a practitioner, academic, and a leading authority in SWE worldwide.

(a) Users, Customers, Stakeholders, System Engineers, and Project teams of any software system DO NOT KNOW anything about the functional requirements of any software system.

(b) Users, Customers, Stakeholders, System Engineers, and Project teams are solution-oriented mental models by experience and practice.

(c) We need to distinguish the difference between System and Software. A unique system exists in domain knowledge, but the SW is the accurate engine in all designs and domain knowledge.

(d) Unfortunately:

(1) SWE Gangs where each gang pushes its agenda in different areas of SWE, creating confusion, pointless debates, poor research, and inadequate teaching and training programs among the SWE universities and communities.

Evidence:

+ In Parnas, David L. (1998), "Software Engineering Programs are not Computer Science Programs." Annals of Software Engineering 6:19-37, Page 19. Parnas said that software engineering is a form of engineering.

+ The Gang of Four Summarize SWE in "Design Patterns," Analysis Patterns," "Process Patterns," and others. Most of them are programmers and from different fields of knowledge.

+ I studied most SWE university programs and found tremendous in various aspects of SWE, and many instructors are (Lecturers) Programmers.

+ "A well-known: All the existing SWE Books have nothing to do with true SWE. Concerning all the authors of any book on SWE areas, they are identical in many ways, even in their major pitfalls and problems.

+ SWE Standards collecting dust has no value.

+ SWE is not a social science or social media.

and

(2) The majority of different disciplines, professional and academia, trivialize SWE:

Evidence:

+ In Knuth, Donald (1974), "Computer Programming is an Art." The Communications of ACM 17 (12) Transcript of 1974, Tuning Award Lecture, where Knuth needed to separate Art and Science in his lecture.

+ In Dijkstra, Edsger W. (1998 "On the Cruelty of really teaching computer science,'" EWD1036, Austin, December 1998.

He also said that SWE should be known as "The Doomed Discipline." He indicated why he used the term "Doomed" because it cannot even approach its goal of science, and its purpose is self-contradictory. Unfortunately, all the non-SWE professionals in Computer Science and Engineering adopt the same point of view.

+ In Edsger W. Dijkstra's (2004) "There is still a war going on," Transcript, Austin (December 1993).

Dijkstra rejected the idea of "SWE" until he died in 2002, arguing that those terms were poor analogies for the radical novelty of computer science. He also indicated that SWE is Miserable Science."

(3) "Requirements elicitation is the practice of researching and discovering the requirements of a system."

There are three bizarre notions in this statement:

a) "The Practice of Research and Discovery" – Wow

Practice: The existing solicitation or gathering requirements failed to Gather the valid SWE Requirements.

Research: The current solicitation doesn't have anything to do with research.

Discovery:?

b) "Requirements of a system" must change to Requirements of Software or Software Requirements

Second: "Applicable (functional) requirements help to keep the project team going in the right direction." True. The reality is that the functional requirements do not exist. Therefore all the software project teams need to go in a different direction.

Third: "Unclear functional requirements lead to a poorly defined scope that creates many challenges from the beginning of the project." True. Why?

+ The cancelations of many systems,

+ Maintenance nightmare,

+ Disappearance of Software

+ Short life spans of much existing software,

+ Failure of 98% of startups, and

+ Legacy systems (Billions of $s)

Fourth: "In requirements engineering."

+ There are no functional requirements and the avoidance of problem space.

+ There is nothing to engineer. I will address many questions related to Requirements engineering."