Requirements: Engineering vs. Management

Which is a subset of the other, is the process of requirements management a subset of requirements engineering or the other way around?

To best answer this question lets get back to the basics. What is "engineering" and what is "management".

The term engineering is used to indicate an activity whereby an engineer utilizes findings of sciences to realize solutions which solve problems. To provide an example, a society which has a problem crossing a river asks a civil engineer to realize a solution to this problem. The engineer based on his readings and input from scientists in the fields of chemistry, physics and materials suggests using a steel structure which can withstand corrosion from the environment, and hot summer temperatures as well as extremely low winter temperatures. The engineer performs calculations to detemine bridge loads and how the structure will behave to cross winds and othe environmental elements.

So back to requirements engineering, it is the process used to determine how to best engineer (recognize, analyze and synthesis) a requirement.

Generally speaking management is defined as the activity of controlling, organizing, planning, and directing. It can be argued that planning and analysis do overlap and hence both requirements engineering and management overlap to some degree, and I would agree with this. However requirements management has a much broader scope than engineering, requirements management plans, organizes, controls and directs the processes related to requirements "handling", this handling includes engineering, development, maintenance and obsolecence. Changes to requirements are considered part of requirements maintenance which is part of reqs mgmt.

Requirements management involves developing a database to store requirements, a report from this database could be the RTVM, a list of configurable items (CIs), requirements management could also include tracing requirements to business requirements upward and to test and verification results downwards, it also ensures that the synthesis process in requirements engineering is sound and consistent and traceable to project work packages in the work breakdown structure (WBS) and eventually the statement of work (SOW). It involves establishing requirements baselines, negotiation with stake-holders and prioritization of requirements and changes.

We should not assume requirements management to be a phase in the system life-cycle, but rather a continuous process overseeing all the phases of the system, nor is it a subset of requirements engineering but rather a superset of the various system phases. This is illustrated in the chart below.

A few papers related to requirements management are listed,

[1] Ian Somerville and Pete Sawyer, "Viewpoints: Principles, Problems and a Practical Approach to Requirements Engineering", Lancaster University, 1997.

[2] James Martin, "A Process for Requirements Definition and Architecture Definition", Texas Instruments.

[3] James Martin, "Systems Engineering Guidebook: A Process for Developing Systems and Products", CRC Press, 1997.

Daring and Leading

A good engineer is one who is daring and leading the stakeholders towards a solution. Younger engineers tend to be more risk taking, which is not always bad. As Pearl Buck once stated "The young do not know enough to be prudent, and therefore they attempt the impossible -- and achieve it, generation after generation."

Daring and risk taking is not wrong and should never be, as long as we manage it. Thats where the whole idea of risk management comes in. Risk management and innovation work hand in hand, and will produce exceptional results if led correctly.

As Eudora Welty once said, "All serious daring starts from within", a good engineer is one who loves what is being worked on, what is being innovated and what is being risked.

Allah (glory be to him) states in the Quran, "Indeed Allah will not change what has been bestowed on a group of people, until they change what is inside of them".

It all starts in the heart and the passion to lead and succeed.

SOA in a Nutshell

Service-oriented architecture has emerged as the means to improve business intelligence, innovation and agility, through developing loosely coupled distinct automation logic units. These loosely coupled automation logic units allow an abstraction of business logic and technology.

SOA encourages units of logic to exist autonomously yet not isolated from each other. In SOA the units of logic are known as "services".

Automation Logic

The automation logic components used by SOA comprise of:

1. Messages: which represent the data required to complete some or parts of a unit of work.

2. Operations: which represent the logic required to process messages to complete a unit of work

3. Services: which represent logically grouped set of operations capable of performing related units of work.

4. Processes: which contain and define the business rules that determine which service operations are used to complete a unit of automation. Instances of processes wherein a group of services follow a particular path through the process logic to complete a task are known as activities.

SOA Principles

Key principles in SOA are:

1. Autonomous services
2. Loosely coupled services
3. Services abstract underlying logic
4. Composable services
5. Formal contracts to define information exchange between services
6. Reusable services
7. Stateless services
8. Discoverable services

Software Components

Systems engineers define requirements at various levels, the highest of those levels is the business level, then comes the enterprise level, then the system level, then the component level. For a physical system a component could be easy to identify, how about software?

One way of defining a component in the software world is an active object with clear self-defined interfaces [1]. Active objects are objects with have their own thread of control.

Another definition is that a component is an object written to specification. Components are defined to meet several criteria namely; multi-use, non-context-specific, composable, contained and of independent versioning [2].

So a component level requirement is a requirement that tells the developer the needs that the code shall be able to accomplish.

[1] Hassan Gomma, "Designing Concurrent, Distributed, and Real-Time Applications with UML", Addison Wesley, 2000

[2] http://en.wikipedia.org/wiki/Software_componentry

Applying the Learning-Teaching Style Process to Jump Start Your Novice Engineers

Working as an elementary school teacher is not an easy job. One of the biggest challenges facing an educator is activating and sustaining the student's motivation.

Richard Lavoie in his book "The Motivation Breakthrough" discusses a four-step process which has been effective with children during challenging times. The process is summarized as follows:

1. Do it for the student - By explaining to the student what needs to be done, we then ask questions about next steps. Using common sense and logic the student should be able to explain what needs to be done to solve the problem. During this step the student is not asked to do the work himself, but only be responsive to questions, actively listening and asking questions.

2. Do it with the student - In this step the educator allows the student the opportunity to do part or all of the work with the assistance of his coach. Upon the completion of this step the student will be able to perform the task, or solve the problem on his own.

3. Observe the student - In this step the educator observes the student doing the work. It allows the educator to evaluate the process of the problem solution and not just the final result. It is a great opportunity for the educator or coach to offer suggestions, praise, clarifications and guidance. Upon completion of this step the student becomes a master in the problem or task.

4. Have the student do it - The student is completely independent and not supervised during the problem solving or task implementation. It provides the student extra confidence and the ability to innovate and improve the process and skills involved.

As Chief Systems Engineers we can apply these concepts to novice team members or new graduates. New members could shadow experienced systems engineers and achieve step 1 and 2 through direct interactions during the shadowing process. Delegation allows the senior team member to observe the junior team member and finally a complete turn-over allows the realization of the fourth step.

Hello I am Your Systems Engineer. How Can I Serve You?

The last thing a systems engineer wants to ask a client during a requirements gathering process or JAD session is "So what features or capabilities do you need?". If the client knows what they need, there is no reason to hire a systems engineer.... right?

So how can an SE find out what a client needs? Asking for what the problems are is probably the first questions an SE needs to bring up. Identifying the problems, the root-cause for these problems, the severity, history and impact are the questions the clients need to hear. Clients understand very well their problems, they usually have a slight idea or thought on potential solutions, and in many cases don't. But all clients will know what their problems are, or at least will be able to explain the manifestations of a problem.

Systems Engineering - Various Perspectives

We are familiar with civil engineering, electrical engineering, mechanical engineering and the many other engineering disciplines. Engineering generally speaking is the application of science and its concepts to solve society's problems. For example a problem of crossing a river can be solved using the sciences of materials, welding, concrete pouring, etc.. through civil engineering which makes it possible to realize a civil solution. Also we can develop a product that lifts people up into the air and cross the river - called a helicopter - through aerospace engineering which makes it possible to realize an aerospace solution. Similarly, systems engineering attempts to solve problems through the realization of a systems solution using the concepts of systems sciences. One difference in the case of systems engineering from other engineering disciplines is that systems engineerings is not only based on sciences of systems, but also on the art of systems thinking.

Here are some perspectives on what systems engineering is,

1. An Engineering discipline focusing on system realization using well developed scientific approaches such as requirements definition, engineering and management; feasibility and trade studies; system interfacing and integration; technical risk control and management; system optimization; system life-cycle management and system modeling and simulation. Systems Engineering has been offered as a post graduate degree in many institutions around the world, mostly at the Masters level. A handful of Universities also offer PhD degrees in Systems Engineering. I expect in the next 10 years we will see B.Sc. degrees offered in systems engineering as a new engineering branch of study, it could also be offered in specializations or as a minor at the undergraduate level.

2. An Engineering approach which combines both art and science. The science of rigorous well-defined engineering theories, processes and approaches, and the science of problem solving using systemic approaches. The art of systems thinking.

3. A management discipline controlling the total system life-cycle. In this case systems engineering is viewed as the interaction of science, organization and the environment and their impact on the system throughout all phases of its life-cycle. It is also viewed as the application of methods, tools and technologies across the life-cycle of the system products.

Performance: An attribute or a behavior?

Is performance of a system an attribute or a behavior? I guess the answer to this question depends on the perspective you are considering. Lets take the example of a Nissan Quest Minivan as a system.

According to its data sheet it has a performance of 235 hp @ 5,800 rpm and a 240 lb-ft @ 4,400 rpm. This data could be considered a system attribute at the time of design. These are the performance goals the design engineers are targeting in the product that rolls off the assembly line. One can argue that once the minivan hits the road and a driver presses on the gas pedal these numbers no longer become attributes but rather operational behaviors. As the system ages the numbers would change.

Enterprise Architecture

Enterprise Architecture is the organizing of logic for business processes to reflect the integration requirements of an enterprise's operating model.

It is important to identify the processes, data, technologies and interfaces that are core to the definition of the operating model. Different enterprises will have different operating models and hence the focus on each of those mentioned areas would be different. For example a wholesaler in the oil industry will focus on processes and data more than a retailer in the finance industry whose focus would be on client data and interfaces.

Some artifacts that could be used as starting points to define an enterprise architecture could be functional architectural diagrams, which would highlight the main functional processes. Another artifact is an external interface diagram. A list of shared data and key technologies linking the various applications also serves as a good defining artifact.

Daddy I Want a Cat Now: A Real-Time System Delimma

It was the first week of school when my daughter came back from school and dashed through the door to remind me of the promise I made last school year. I promised her that in the fall we can buy the cat she always wanted. I was faced with a real-time problem. I had to make a decision on the spot to accommodate her request. The 8 year old has been patiently waiting for 3 long months to invite that little creature into our home. Opposed to the idea of having one, I had to delay until she can prove herself responsible to care for little kitty.

So as humans we get faced with real-time problems, and we need to deal with them in intelligent ways to avoid long term damage, and short term devastation. The human real-time system shares some similarities with a real-time software system processing delay-sensitive service requests.

So what are the key attributes of a real-time system? In a nutshell it is a system that must produce accurate computational results and these computations must conclude within a predefined period. These two attributes are known as the functional correctness and timing correctness of the system, and both have equal importance.

Another key aspect of a real-time system is that is has awareness of the environment in which it exists and applications it hosts, hence it is considered deterministic as the responses to service requests are time bound. This deterministic response behavior makes a real-time system less adaptive to changes in the environment. We can easily see the dilemma faced by real-time systems operated in highly dynamic environments. A balance needs to occur between the deterministic response and the adaptiveness of the system.

The same applies to a parent's situation with his/her child, a deterministic response is needed and expected by the child. After waiting all these months for kitty and behaving well during the summer break, the child expects a real-time response. The child will not expect "ok, let me think about it". A decision has to be made on the spot, hence the time boundness. Additionally the parent is aware of the consequences of denying or approving the request. In the former case the child will be devastated and will accuse parent of not holding on to promises, in the latter case kitty will go on hunger as the child is still not responsible enough to care for kitty.

This kitty real-time system involves (1) a service request initiated by the child to own a cat, (2) a decision-maker processor - the parent - and (3) the external environment - the child's attitude. Do the laws of embedded real time systems apply here? They probably do, however it is a lot more complex than a technology real-time system such as a missile defense system and involves psychology, social behavior and various other domains of art. A missile defense system involves a human element in the decision-maker process to fire or not to fire, however the system element expecting the real-time response is not a human, it is a missile launch pad, and its behavior is well understood. In the example of the kitty, the child's behavior to the parent's real-time response is not clearly understood, it could manifest itself in a sudden outburst of tears and crying, an acceptance accompanied with long term dissatisfaction, short term happiness, etc... modeling and predicting human factors is a whole other story...

Common Software System Development Methodologies

There are 4 common software system development methodologies. These methodologies comprise of:

(1) A process - to define activities or tasks to achieve the goal of the methodology
(2) A vocabulary - to describe the process and work products created during the process application.
(3) Rules and guidelines - to define the quality of the process and the work products

The four methodologies are shown in the table below along with their strengths and weaknesses.

Domain	RUP	Shlaer-Mellar	CRC	XP
Emphasis	- Incremental and iteration	- Execution for verification	Scenarios and simplicity	Simplicity, design through integration and refactoring
Strengths	- Comprehensive - Well Defined artifacts and roles - Incremental deliveries	- Simulation capability - Well defined testing rules - Well defined transition from one step in the process to another - Real-time system support	- Simplicity - Easy to use to transition from procedural to object oriented concepts - Focuses on object value, leading to optimized system	- Focuses and cares about the programming environment - Supports and requires close relationship between clients and developers - Accounts for changes in the development process
Weakness	- Large and difficult - Complicated rules - Customization is not straight-forward - Limited vendors supporting the process	- Considerable learning curve - Focuses too much on state modeling. - Limited vendors supporting the process	- Supports primarily classes - Requires a facilitator	- Relies on an ideal development environment - Depends extensively on client commitments - Requires high quality human interaction among development team - The system is in a constant state of maintenance

A System for Innovation

Diversity in our lives brings a wealth of knowledge and experience at unexpected ways. There are many facets to diversity; examples are age diversity, education diversity, background diversity, interest diversity and the list can go on.

Imagine if all people were interested in playing basketball, then all what the world will know is basketball. Now with the presence of soccer, one can think and say, what if we come up with a game that has some attributes of basketball and some of soccer, and call that game handball, just an example. This diversity in the athletic domain can yield new types of games. Not only that, but also consider for a moment how a team can lead innovation based on experiences from basketball as a knowledge domain. There are many areas, team work, flexibility, adaptability, endurance, and probably a dozen other areas of knowledge.

This weekend I had the privilege of hosting a couple of my friends' teens at home. Being a married professional my late 30s, most people I deal with are professionals around my age or a bit older or younger, as well as my spouse and young girls. How often do I interact with a 14 or 16 year old? The answer is not very often. Spending an evening together pondering on the creation of Allah (SWT), and reading from his book, and then hanging out at the gym together the next morning has given me a very interesting insight. "Strong nations need and must communicate across all sections of the society". The old and the young, the senior and the junior, the poor and the rich, and so on ...

This should be no surprise to a systems engineer, as Allah (God) tells us in the Quran that God has created us from a male and female and make us into tribes and nations to know one another and to know that verily the most honorable among you are ones who have the most piety.

يَا أَيُّهَا النَّاسُ إِنَّا خَلَقْنَاكُم مِّن ذَكَرٍ وَأُنثَى وَجَعَلْنَاكُمْ شُعُوبًا وَقَبَائِلَ لِتَعَارَفُوا إِنَّ أَكْرَمَكُمْ عِندَ اللَّهِ أَتْقَاكُمْ إِنَّ اللَّهَ عَلِيمٌ خَبِيرٌ

Allah has created diversity. Diversity in gender - men and women - as well as in color, demographics and place of origin. This diversity if put to action correctly in compliance and adherence to the guidance of Allah, we will not only succeed in this life but also in the hereafter.

On the other hand, we are also diverse in levels of piety and belief. As humans we can recognize this through contrast and comparison to other groups and nations. Someone who is not on the right path can easily identify so by seeing or dealing with someone who obeys his Lord and fears the consequences.

In just less than 30 minutes with two teens, I was able to learn about every single piece of workout equipment in a room the size of about 70' by 40'. In an hour we tried out almost 75% of the equipment. So you probably ask now, whats so interesting about this? What is interesting is the unexpected power of knowledge developed by mixing the teen and the 30 year old ideas, thoughts and passions. My younger friends provided a blend of motivation, risk assumption, willingness to explore and hastiness. I pitched in with risk control, analysis, prioritization and feedback. Now lets consider on the other hand that I went to same gym with the parents of my young friends - i.e. my friends - would we have explored those dozens of equipment? Would we have attempted to try half of what we tried out? Would we have motivated each other and encouraged one another to try out equipment... I can guess probably not. Imagine going with a newly retired friend who is in his 60s .. what experiences can we expect and imagine ?? Probably a lot more that are different from those discussed above, adding even further wealth. Humans need to mix across generations, not only for social purposes but also for strength and growth purposes...

This is definitely a complex topic, involving tens if not hundreds of factors... The main point to take out of this discussion is that "Diversity leads to new experiences, these experiences could be good or bad. In either case the experiences tends to be of large dynamic nature", and we should understand its implications very well to better control it, and leverage it to innovate and grow stronger.

Organize Your System: Architecture versus Framework

Architectures and frameworks are among many other artifacts that could be used for organization. So what is the difference between an architecture and a framework?

Architectures define a unified structure of a system. It is concened with the purpose determination, concept, structure, use and behavior of the system. Architectures could be physical, operational, technical or functional.

Frameworks define the data and information that needs to go into an Architecture. For example a framework will define that a functional architecture will include functions, inputs and outputs of these functional blocks, controls and maybe actors performing these functions.

Common frameworks are DOD Architecture Framework (DODAF), The Open Group Architecture Framework (TOGAF), Federal Enterprise Architecture Framework (FEAF), and they define what needs to be in a C4ISR Architecture, Enterprise Architecture and a Federal Enterprise Architecture respectively.

More to come on this topic soon...

Which Soft Skills Do You Consider the Most Important?

The discussion about soft skills and their significance in engineering fields is getting more attention. Soft skills such as active listening, interpersonal skills, emotional intelligence, conflict resolution, negotiation, and the list goes on... are becoming increasingly important and strategic. Engineers are no longer confined to their cubicles within reams of sheets of drawings and calculations.

Engineers are out in the field discussing needs and capabilities with clients, leading technical meetings, discussing details with suppliers and vendors and communicating with other professionals across the globe using collaboration tools such as instant messaging, IP conferencing and real-time audio and video communications.

Which ones in your opinion are more important than others?

Software Systems: What is Your Type?

Software systems are all around us. In the car, microwave machine, washing machine, traffic lights, bank, Internet, and just about every place we go to. The big question is how different are these software systems from one another?

Some software systems mission is to store data so other systems can retrieve it and process it. The Internet and a complex database cluster system are two examples. Other systems process data and provide results such as credit card processing systems and airline reservation systems. A third software system is one embedded in some control logic on an appliance like a microwave program or washing machine, and the list goes on...

We have heard of the terms pervasive computing and pervasive networking. They refer to distributed computing elements connected via a complex communication network allowing tight integration into our lives. An example would be a network of sensors communicating with one another and a number of management nodes.

Can we define a new type of software system called the pervasive software system? One which is deployed on a large number of computational devices across a complex network, each device performing a custom computational task - dependent on the devices location and mission, which could be time dependent - and sending the results to a larger "master" computer.

Note the difference between the pervasive computing and pervasive software is that in a pervasive computing environment the various nodes are dispersed, but each has a fixed computing configuration - fixed hardware and software. The pervasive software system on the other hand is a software system broken into pieces each running remotely on its own pervasive computer, and these software pieces could be reconfigurable and dynamic according to where the pervasive computer is and what its mission at a particular point in time is ...

Technical Arguments

In order for a systems engineer to come up with a decision, there has to be a solid argument. Arguments are not conflicts, but rather expressions of ideas with evidence and facts. Arguments should be verifiable and are not based on emotions.

I am teaching a debate class for middle schoolers this weekend. So what is the link between that and this blog. Well, everyone needs to debate. Debate is not just for politicians, attorneys and TV host shows. Engineers need to debate technical ideas, requirements and design constraints. the systems engineer needs to ensure that technical arguments are backed up by solid facts. These facts need to be verifiable, just like requirements.

Teaching engineers how to debate is as important as teaching attorneys how to present a case in court. Dealing effectively with complicated and complex systems requires no only engineering and science, but also art in the form of architecture, soft skills and critical thinking.

Decision Making and Systems Engineering

Systems engineering is an interdisiplinary approach to enable the successful realization of systems. Learning the systems engineering process is not a complex task. The tough part of systems engineering is making decisions related to trade-off studies, and balancing among the different requirements, which could at many times be orthogonal and conflicting.

An effective systems engineer is one who can provide insights and advice related to technical decisions. This would occur as follows,

1. Ensuring requirements are clear, well understood, correctly prioritized, and motivation well understood
2. Modeling and simulation and developing what-if scenarios
3. Conducting trade studies and parametric analysis
4. Clearly defining interfaces and boundaries, their requirements and impacts
5. Comprehensive risk management and optimum risk handling
6. Justify changes to requirements, design, scope, resource demands and technology
7. System optimization to develop a best solution in situation where multiple aspects of a system can be optimized
8. clearly defining dependencies, integration constraints and alternatives

The value of the system engineer is not only implementing the systems engineering capability pattern, but also ensuring that true value is being realized through the implementation of the SE capability patten. This true value will be achieved through solid decision-making.

A World of Decisions

Very often we get challenged to make decisions on problems which have more than one criteria. This decision making process is referred to as "Multi-Criteria Decision Making (MCDM)".

MCDM defines two major classes for determining optimal decisions. The first known as Multi-Objective Decision Making (MODM), and the second Multi-Attribute Decision Making (MADM). Both classes could support single or multiple decision makers as well as multiple data types -deterministic, stochastic, or fuzzy.

MODM deals with problems in which the decision space is continuous. MADM on the other hand is used when solutions are discrete.

The key point in making decisions is not what one is deciding, but rather how the decision is made. The ability to make sound decisions is a fundamental life skill, each one of us experiences everyday.

To read further:
1. Tryantaphyllou, Shu, Sanchez, and Ray, "Multi-Criteria Decision Making: An Operations Research Approach", Encylopedia of Electrical and Electronics Engineering, John Wiley, 1998, pp. 175-186.

2. Hammond, Keeney, Raiffa, "Smart Choices: A Practical Guide to Making Better Life Decisions", Broadway Books, 2002

Squeezing the Last Bit out of a Technical Review

Often times on projects with extremely tight schedules and very short durations, the project team does not have the time to document kep aspects of a system. For example external interface specification may not be documented in the form of an Interface Configuration Document. However the designer might have opened change requests/engineering changes and documented what the impact on the interface would be. This practice could lead to missing some requirements, or not looking into all interface design issues.

In situations such as the above (you have a 4 week project to develop a large system, no time or resources to develop a true "ICD") the system engineer feel helpless. One key authority the system engineer has is to use the critical design review to gather these requirements which are all over the place. For example, using the ICD example above, the SE can ask questions like, 'What impact will this CR have on the external interfaces?", or "What test requirements are needed to verify this CR". Capturing this information into a table, the SE can then later reverse engineer a systems interface requirement document, or an ICD.

Technical / Scientific Reviews Leadership

We had a guest speaker come in from Johns Hopkins APL to our leadership class at UMBC last night. He shared with us his career experiences and some tips.

One thought I got from his visit was the importance of teaching technical/scientific review meetings leadership. I did a search on the Internet quickly to see what is out there, but there is very little literature in how to successfully run and conduct a technical review.

I am not talking from a process perspective, like what the process for an SRR should be. These processes are well known and understood. But rather I am talking from the leadership perspective. Areas like

1. Tools
- What are the best tools to use during the review, slideware, spreadsheets, technical documents, etc..
- Can reviews be conducted remotely over collaboration S/W like NetMeeting, Notes
- What is more effective in-person or remote meetings? I did both each has it pros and cons

2. Negotiation schemes
- So the client PM takes over the meeting, how do you as the lead SE on the contractor side react?
- Just got into a project yesterday, you need to do a walk-thru tomorrow, who are players? how to run the review smoothly?

3. Time control
- Mr. chatter loves to chat, and whiner complains about each requirement, and repeater has to make sure we all memorize his statements before we leave, how to filter and weed out the garbage talk and retain the technical meat you are looking for?
- One big 8 hr meeting with 1 hr lunch and 2 15-min breaks, or 4 2-hr meetings over 4 days?

4. Scope control
- Ok, we are doing a use case review, but lets quickly go over the architecture, 60/40 opposition, what do you do?

I attended a workshop by Edward Tufte, the professor at Yale last Spring, he discussed some very interesting thoughts about how some organizations fail to conduct reviews simply because they use poor tools. He gave the example of NASA and the shuttle explosion. In his opinion as well as the many experts who evaluated the crash, the failure in the shuttle started not at launch, but rather way back in the technical review process. NASA was too heavily dependent on power point fluff. It was very easy to lose focus of the strategic technical issues and questions during the reviews.

This all needs more research...