I want to describe requirements for a computer program and I'm having trouble.

As a context, I think a concrete object in the real-world is something detectable by one or more of the senses (feel, see, ...). An abstract object is a notion about some aspect of a real-world object or another concept (e.g., the playfulness of angels).

But in software everything is abstract. The entities in software are all abstractions of real-world objects (a person, a bank account, an aircraft) but also of 'abstract' attributes of objects (the usability of a user interface, the complexity of a program).

Is there a taxonomy or convention for defining these different types of things?

Another s/w developer viewpoint is that entities (things in the world) have attributes. Entities are distinguished from one another by their attributes: either by the attribute values or the set of attributes associated with an entity. Entities that share common attributes are said to be "of the same type." Turtles have one set of attributes; they are (mostly) disjoint from the attributes of an espresso machine.

So how can I categorize requirements in accordance with the type of thing to which the requirement refers? Concrete object in real-world vs. measurable concept about a real-world object vs. abstract characteristic.

Thanks (forgive the many words, Pascal's apology applied here). --dave

  • 1
    This is not a question about philosophy, but about conventions in software engineering. I would take this to softwareengineering.stackexchange.com or possibly stackoverflow.com – M. le Fou Nov 7 '16 at 2:24
  • Also, what is wrong with the categorization you give in the 2nd last paragraph? (Concrete object in real-world vs. measurable concept about a real-world object vs. abstract characteristic) – M. le Fou Nov 7 '16 at 2:46
  • 4
    There is an active discussion in US courts as to what does and does not qualify as "abstract ideas" in software. This has direct legal implications as "abstract ideas" are not patentable, and the courts did a lot of work in drawing distinctions, see Software patents under United States patent law. On this angle you may want to ask on Law SE. – Conifold Nov 7 '16 at 19:23
  • Question is not really about software engineering. I used SWE as a means to explain what I'm looking for. – user1704475 Nov 7 '16 at 22:31
  • Hi. "I want to describe requirements for a computer program and I'm having trouble". Could you give some specific examples of "requirements" that cause you trouble? – Ram Tobolski Nov 7 '16 at 23:39

Welcome to the fun of software engineering jargon! At work and play, I have run into the problem of shared terms a lot when it comes to designing software systems. Sorry if I don't answer your question properly, there seems to be a lot in it and I find it a bit nebulous. I'm going to answer the actual questions in the content with, "be careful and clarify where necessary in your documentation or presentations to teammates and users." Here is some lingo you can use, though:

"functional requirements" - What goes in and what should come out?

"architecture" - How will it be built? What are the tools and patterns involved?

"logical design" - How does everything in the virtual realm fit together and maintain its structure? What are the rules of the system? This relates to "entities", those abstractions of concrete things from real life you were talking about. Rules about data tables, attributes, etc. need to be outlined in an "entity-relationship-diagram."

"look-and-feel" Overall vibe - colors, clicks, animations, graphic design

"user experience" - Also called ux. Self-explanatory.

"interface" - How components or users connect to the system.

"physical design" These are the 'physical' requirements for the program(s), what input needs to be entered? (easy example: a date field in a webform should only accept a date). This may also refer to more concrete elements from the real world, such as the type of computer or other instrument hypothetically being used with the software system.

Also, I will say that a program does not care very much about whether the attribute being recorded is "concrete" or "abstract". If you want to record the number of passengers on a plane, you would use a field just the same as if you wanted to record the maintenance status of said plane (good, fair, poor, etc.)

If you are, specifically, looking to understand the meaning of concrete and abstract classes within the scope of object-oriented programming, let me know and I will go into detail on that topic. I'm to understand that you are a consumer, not a creator, of software products, though.

As you can see, there is tons of shared terminology just in this post and plenty of overlap in the content that these terms cover. Thus, my initial answer of being careful and clarifying will always apply. If you want to dig deeper or have more questions, I'm happy to expand upon my answer and maybe do some research, too.

| improve this answer | |
  • Thank you Oscar Wilder! Clear explanations. Also, I'm jazzed that you mention ERD's. They are my bread and butter, learned them at Uni in 1985--the same quarter that Bertrand was teaching us Eiffel--and completely ingrained them in my practice. Additionally, I learned something from else: diff between "architecture" vs "logical design," that is keenly interesting. – user1704475 Nov 18 '16 at 18:58

There are a variety of ways of describing various kinds and levels of abstraction in programming.

Some constructions used in programs are more abstract than others. For example, you might apply a function f to the numbers 1 to 5 like this: f(1),f(2),f(3),f(4),f(5), or you might write a for loop for(i=1..5,i++){f(i)}, or you might use a higher order function like map in a lisp: (map f (range 1 6)). These are listed in order of abstraction from least to most abstract.

There are different programming paradigms, e.g. - object oriented programming, aspect oriented programming and functional programming. They place emphases on different kinds of abstractions.

There is also a lot of material on types in programming that has some connection to abstract philosophical and mathematical material like type theory:


Programming languages that emphasise types include Haskell and Idris.

My guess about the solution to your problem is to ask a programmer to solve it. Or you could look up some particular paradigm like functional programming and see if it fits how you think about the problem.

| improve this answer | |

I'm just going to tackle your headline question on the distinction between abstract & concrete.

The notion to tackle here, in computer science terms is in whats called type theory; its not neccessary though to go into great detail; and its useful to pursue an analogy with set theory here.

A type names a set; the desiderata that specifies what this type entails is like the defining conditions of the set; the actual objects that satisfy these desiderata exemplify the type, in set-theory speak these are the elements of the set.

For example:

integer is a type,

and the integers 1,2,3,4,... are objects that exemplify this type

we can write integer = {x is a real number: x - floor x is zero} = {1,2,3,...}

Types are abstract, and objects are concrete; one way of thinking about this, is that a type abstracts from the a set of objects their common defining properties.

There is a connection here with Aristotles notion of genus, species and differentia; a type would be a species, a supertype would be a genus, and a differentia is the defining conditions.

In the above example:



differentia = defining conditions = 'x - floor x is zero'

Hope this helps.

| improve this answer | |
  • Thanks, Mozibur, for your clear and helpful explanation. I appreciate it very much. – user1704475 Nov 18 '16 at 19:12

From things that you wonder:

Is there a taxonomy or convention for defining these different types of things?


So how can I categorize requirements in accordance with the type of thing to which the requirement refers?

I guess maybe you are asking if there is any right way of mapping requirements to language construct(e.g. class in object oriented language like Java,C++). I think you will get clear of it after you finish some demos or projects in production, I just want to explain some process of the abstraction process you mention.

Well, it's obvious that a software that fulfill the requirement can serve as we expect(at least for the moment), this may includes: user interface is ok, request processing is ok etc.

So it is common that there're several or even countless possible implementations to achieve the result above, and each of the implementations is valid.

For example, for an online store site like amazon, consider the following two modeling in different implementation:

In implementation 1, we model product as a Java class called Product, and model the customer comments below it as a Java class called Comment:

/* impl 1 */
public class Product{

public class Comment{

In implementation 2, we model product with comments as a Java class called Product, as we consider product and comments as a whole, and comments, which is a list of string, is a private attribute/member of Product class:

/* impl 2 */
public class Product {
 private List<String> comments;

Both implementation can be valid. But answering whether an implementation is right often means go through some criterion:

  • Whether the abstraction of concept is clear. Unclear concepts may cause other collaborator hard to understand and use the model/class, or hard to add functionality in the future(i.e. extensibility). Choice includes separate some concepts or group them in a single concept which is just what we face above.
  • Whether the language, framework, architecture we choose is a proper one. These are often big choices and also choices not so easy to decide, and we can't discuss this in detail without an real world example.

Other aspects include code readability, system scalability which varies much in different types of projects(e.g. backend vs frontend, large scale of users vs. small scale of users, normal device vs resource limited device)

These are some aspects that an implementer or an architecture may consider which may related to the distinction of good design and bad design.

| improve this answer | |
  • 1
    Software was really just an example in the opening post. Can you clarify how this answer relates to the philosophical issues the question attempts to point at? – user2953 Nov 8 '16 at 12:17

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