Telling Your Story

Computer Aided Software Engineering (CASE) and Unified Modeling Language (UML) provide means for Systems and Software Architects/Engineers to describe their architecture using many different methods and standards. As an Architect and Engineer, I have been doing this for more than 30 years.

So What Is A Story?

A story is a narrative, either real or fictional, that is told or written to entertain, inform, educate, or convey a message. It typically involves a sequence of events or experiences that are connected in some way, often following a structure that includes a beginning, middle, and end.

A story typically includes various elements such as characters (who the story is about), a setting (where and when the story takes place), a plot (the sequence of events or the storyline), conflict or challenges that the characters face, and a resolution or conclusion that brings the story to a close.

Stories can take many forms, including novels, short stories, folktales, myths, fables, plays, movies, television shows, and even anecdotes shared in everyday conversations. They serve as a means of communication and are used to entertain, teach, inspire, provoke thought, and evoke emotions in the audience or readers.

What Is A Story In Architecture

In Modeling (e.g., CASE, UML, or other), the whole purpose, in my opinion, is to tell your "Story". Various modelers may have various perspectives in telling "the story". 

• An Architect is creative while an Engineer is more logical. 
• A Client may be non-technical and tell stories in their active voice, creatively or logically.
• A Requirements Engineer follows a defined and repeatable practice and processes, starting with Elicitation, then Analysis, followed by Specification, and closing with Validation.

There are all sorts of methods (ways) to tell your stories. Modeling is just one of those ways (approaches).

When telling a story it's good to have guides in place, such as Checklists, to ensure you are following an approach to presenting your story. After all, humans use a repeatable and defined process in telling their stories, but may not be consistent among other humans. In modeling, there are various Templates, Layouts, and Artifacts the story is produced in, or with. Your models help with consistency and validation.

More importantly, it's good to "Test" your stories from start to finish (or publication). Thus, we have a Test Case which contains, at least, an Integration Test and Acceptance Test. Integration Testing validates how chapters and stories mesh (or integrate) with each other for consistency and conformity purposes. While Acceptance Testing validates how both "Subject" and "Wrap Up" or "Closing" are acceptable to the stakeholder (reader, user, or machine). The term "acceptable" must equal "true" in the end. For example, was the subject (questions, concerns) answered or concluded effectively?

 Where to Begin?

Start simple! The process should be natural, and don't make it complicated  Just start dumping thoughts or act like you are telling an everyday story to another friend or family member. Remember from school, a story is typically comprised of a few key elements that work together to create a narrative.

These elements include, but are not limited to:

• Characters or Actors: The individuals or entities that drive the story forward. They have personalities, motivations, and conflicts.
• Setting: The time and place where the story unfolds. The setting can greatly influence the mood and atmosphere of the narrative.
• Plot: The sequence of events that make up the story. It includes the introduction, rising action, climax, falling action, and resolution.
• Conflict: The central problem or challenge that the characters face. It creates tension and drives the narrative forward.
• Theme: The underlying message or main idea of the story. Themes often explore universal concepts or human experiences.
• Point of View: The perspective from which the story is told. It can be first person (the narrator is a character in the story), third person limited (the narrator knows the thoughts and feelings of one character), or third person omniscient (the narrator knows the thoughts and feelings of all characters).

In modeling, Actors can be humans or machines (systems). It's important to differentiate between Actors so that we can understand the different perspectives (points of view). The Plot, or sequence, is important to understand the "Flow(s)". The "Conflict" is very important to build problem statements, constraints, rules, and risks. The "Theme" is the whole idea of writing a story, especially when modeling the systems and functions. Creating points of view, or perspectives, can be the more challenging exercise if we are not working with a team.

During the Requirements Development phases, it's important to start with the non-technical stories and let technical aspects come in later. For example:

"The customer drove home from work and sat down to pay bills online".

From this first sentence of the story, we define the Actor, they drive, they have a home, and they work. We also set the "settings" around a home computer, internet connection, and digital account(s). Building a Use Case Model from this one sentence lets us provide "Scope", at least one "Use Case", and one "Actor".

The remainder of the story may add other Actors and Use Cases to work with. This may also lead to more Systems, Perspectives, Challenges, and Settings.

Conclusion

Too often, I join a team and during the first day, problems are developing simple business requirements. While I listen for one or more hours, I have to stop the team and say to client sponsors, in a calm voice, "Tell your story!", "Don't try to be an Architect or Engineer!", "Just tell your story in your own words".

We will talk about this often in our UML Operator Channel. A couple of videos to start with:

• Traceability Telling Your Story
• Telling A Story Deep Dive

Happy Modeling!😎