Building Applications with Deep Learning: Expectations vs. Reality

Abstract

Nowadays, building applications involves many technologies. There are technologies to render user interfaces, to retrieve and store data, to serve many users, to distribute computing, etc. Increasingly, certain requirements imply the usage of neural networks. So what is the reality of building enterprise applications with the available state-of-the-art neural network technology?

Expectations

I am not a scientist. I am curious, like to understand how things work, have analytical aptitude and love math, but… this is not what I am being paid for. During working hours, my task is to develop real world applications in timely and cost-efficient manner. And thankfully there is plenty of available technology aka tools aka frameworks that allow me to do exactly that. Without understanding of magnetism, I am still able to store information. Without understanding query optimization principles, I am still able to write efficient data queries or, without knowing how to fill memory of graphic card, I am still able to render user interface on the monitor. There is even this funny quotation[1] from definition of technology on Wikipedia:

“(Technology)… can be embedded in machines which can be operated without detailed knowledge of their workings.”

I expected that using Neural Network Technology is not different. That I could, merely by obeying the constraints of the design of a framework, applying patterns, avoiding anti-patterns and gluing it with all the other relevant technologies, develop real world application without detailed knowledge of every technology I use. If I still haven’t convinced you, read on here…

Reality

The reality is very different. Someone willing to employ neural network technologies at the moment[2] is forced to do scientific work or at least have an in-depth understanding of neural network methods, despite a number of publicly available technologies created by the brightest and most resourceful minds of our age.

 

Sure, for a plethora of reasons such as – the technology is not mature enough, some fundamental issues are still unsolved, there is too little pressure from industry[3], etc. However, there are some reasons that are focus-related. I will address those which became obvious to me during work on a real-world application. In particular:

  • Kicking-off with the Technology
  • Tools to move from experiment to the real application
  • Development Language
  • Design of Deep Learning Framework

Coming to Terms with Deep Learning

Background Story

Our project started 2014 with the development of recommendation engine for finding solutions in a text-corpora based on documented customer contacts with an after-sales support organisation. After successfully implementing a number of use cases based on statistical approaches with token frequency, collaborative filtering and number of data quality improvements involving, among others, advanced natural language processing techniques we have rolled out a number of productive systems.

 

In 2016 we turned our attention to Neural Networks and Deep Learning. Having great success with Java (actually, Scala), Spark and the available Java-based machine learning frameworks our first choice was deeplearning4j[4] Version dl4j-0.4-rc3.9 (aka dl4j).

 

It was spring 2016, and we got annoyed with dl4j. In retrospect, I see the main drivers of our annoyance were less the framework itself and more our expectations. What we expected, was a yet another robust enterprise framework. Ok the “0.4” and “rc” in the version number should have given us a hint on the maturity of the framework, but we were ignorant. At that time, making dl4j to work for us was complicated, we did not manage to make it run on GPU backend, and even to make the CPU backend work, we had to compile the framework ourselves, which felt like too much additional work that kept us from fulfilling our main task – implementing a neural network that would learn stuff for our use case. After two months of trial & error and parallel experiments with a well-known Python-based framework we decided to switch to that Python framework and suspend work on the dl4j-based network implementation. Oh, the configuration of Python framework was as complicated as that of dl4j, we just got more lucky with it, that’s all.

 

By the end of November 2016, seven months later, we still hadn’t managed to build a network configuration that would converge with data from our domain. After the initial success with building toy models (MNIST, seq2seq and some other models) we had decided that the Python framework was the most promising, but boy did we err. There were plenty of assumptions about what we could have gotten wrong, but there was no visible direction that would enable us to succeed.

 

At that time, a colleague of mine, Wolfgang Buchner[5], mentioned that he has recently saw that dl4j had undergone a major re-vamp. We immediately attempted to build an experimental model with dl4j Version 0.7.2 and within two weeks, we actually succeeded. Within the next two weeks, our model converged to a satisfactory level with our actual data. Four weeks.

 

Of course no one was very optimistic at the beginning, thus the result surprised us. Reflecting on this surprise, I attempted to analyze the main factors that, in my opinion, helped us succeed, and I came to the conclusion that there were four.

Kicking-off with the Technology

There are times when it’s OK to skip the documentation and move straight to the code. I personally don’t often need to read documentation to understand a framework providing the MVC pattern or ORM framework, because these are well established patterns that are provided by well established frameworks.

 

In case of neural networks I do have to read the documentation, if they have it at all at all to kick off a project. Sure there are plenty of papers on arXiv, great lectures on YouTube from renowned MIT professors on KLD, Entropy, Regressions, Backprop and whatnot. But theoretical explanations of principle, and the capability to write the code that implements those principles, are two very different animals.

 

Dl4j has two strengths when it comes to helping someone at the start:

  • Documentation. Framework documentation is not my first choice to understand principles, but definitely the first choice if I want to be able start writing code really fast. Reason being – it focuses on making things work instead of explaining algorithm working principles in-depth and it focuses on end-to-end use cases including pre-processing data and giving advice on the “dark art” of hyper-parameter tuning. This I have never seen in the documentation of other deep learning frameworks;
  • Community. I have been hanging around in every deep learning community I could find. Dl4j has the most vibrant, active, patient and open community I have experienced. Yes, most of the answers still come from Skymind people but there is always someone on dl4j gitter channel[6] who has a couple of good hints up their sleeve.

 

In general, I have the feeling that the intention of dl4j community is to build real applications. Based on my experience with other deep learning communities I feel that their intention is to discuss topics of their ph.d. thesis or prove this or that theorem.

Tools to move from experiments to real applications

Dl4j is an ecosystem. And as an ecosystem, it provides number of tools to pre-process data or read it from different formats, to integrate the framework with other (e.g. consumer) technologies and to semi-automatically tune the hyperparameters of my model.

 

There is one single tool provided by dl4j above all others that had a massive impact on the success of our project so far. It is so called the dl4j User Interface, or UI. It is a web page automatically created by the framework (with minimal configuration, literally five lines of code) that shows graphs of some parameters during network training:

val uiServer = UIServer.getInstance()
val statsStorage = new InMemoryStatsStorage()
uiServer.attach(statsStorage)
listeners +:= new StatsListener(statsStorage)
model.setListeners(listeners: _*)

 

By itself, that would be fine, if you can “read” this analysis data (which, by the way, does not happen by default). So dl4j goes step further and provides extensive and very concrete documentation[7] on how to interpret and analyse the readings, even providing very particular advice on tuning my network configuration. That really made difference for our project. I am posting the picture of the UI below, but seriously, just navigate to the visualization documentation page of dl4j, and you can read about it in a way more detail.

Development Language

To my astonishment, most of the deep learning frameworks are implemented in dynamic (type) languages. Dynamic typing is a good thing in many cases, but I believe it is the worst possible choice when developing deep learning software.

 

If you have already worked with some deep learning framework(s), haven’t you wondered why each and every framework provides a number of classes that download, pre-process and feed the data into neural network? I haven’t seen such a thing in any other class of frameworks but I have a guess as to why it is so: namely, because the data has to be quantified and formated in rather complex structure and the transformation of data in a form readable (and learnable) by network is damn difficult.

 

And then we have this dynamic language, that is so implicit that I literally NEVER know what the hell method A or method B is returning. And when I look at method A, I see it is calling at some point the method A’ which in turn calls A’’ and so on and so forth until I reach the bottom of the stack where the data array is instantiated. By the time I reach the bottom, I have already forgotten what I wanted to accomplish and am trying to figure out the implementation of some utility method of the framework.

 

In the domain that is so data-centric, where data structure is so important and models’ ability to learn is so dependant on correctness of data, how for heaven’s sake can someone select dynamic language as the development language?

 

Fun fact: when you create matrix(10, 255, 64) for training a Recurrent Neural Network in a well known framework, you get 10 sequences of 255 elements of size 64; in dl4j, instead, you get 10 sequences of 64 elements of size 255. How is that not important to know in advance what data structure what method would return?

 

Dl4j is developed in Java. And although Java itself is not the most innovative language out there, it offers two things extremely important to me and my teammates: type safety and its youngest “cousin” Scala, one of the languages best adapted for machine learning out there.

The Design of the Deep Learning Framework

What is available out-of-the-box versus what has to be built by ourselves is an important issue. My observation is that many frameworks are built with only a limited number of use cases in mind, and all the deep learning frameworks I have encountered have mainly research in mind.

 

One major design advantage of the dl4j from version 0.7.2 is its ability to switch backends without re-compiling the code. The class-path is being scanned for the backend libraries and the available backend is loaded automatically. The obvious advantage is, to be able to run the code on CPU while testing locally and, to run the same code on GPU when deploying on a GPU-Rig. Another advantage is to be able to do backend specific stuff. Consider this code:

import org.nd4j.linalg.factory.Nd4jBackend
import org.nd4j.linalg.jcublas.JCublasBackend

/**
 * We need the Nd4JBackend just for determining if we are using 
 * CUDA or CPU, Dl4j uses its own instance.
 */
private object Nd4jBackendHolder {
  val backend: Nd4jBackend = Nd4jBackend.load()
}

/**
 * Trait supporting Nd4jBackend dependent configurations.
 * E.g.:
 * {{{
 *    BackendType match {
        case CUDA =>
          import org.nd4j.jita.conf.CudaEnvironment
          CudaEnvironment.getInstance().getConfiguration
            .setMaximumGridSize(512)
            .setMaximumBlockSize(512)
        case CPU => // do some CPU specific stuff
      }
 * }}}
 */
trait Nd4jBackendUtils {
  import Nd4jBackendHolder._
  
  trait BackendType
  
  case object CPU extends BackendType
  case object CUDA extends BackendType
  
  val BackendType: BackendType = backend match {
      case _: JCublasBackend => CUDA
      case _ => CPU
  }
}

 

With this simple trait you are able to e.g. configure your model differently based on available backend. We set the batch size based on available BackendType because e.g. GPU is able to process larger batches more efficiently:

object TrainingJob extends Nd4jBackendUtils {
   val dataIter = new AsyncMultiDataSetIterator(
      new SegmentedThoughtCorpusIterator(inputFiles, ... train = true),
      batchSize = BackendType match {  256
         case _ => 10
      }
   )
   ...
}

 

The well-known Python framework broke our back when, in an attempt to improve the convergence of our network, we tried to implement number of custom layers (e.g. Stochastic Depth). Because of the design of that network, there is literally no possibility to debug a layer, the usage of backends (the ones who do the heavy lifting) was so unintuitive that we literally were guessing what the design should be, and since everything we wrote was compiled without problems and failed only in runtime, this attempt turned into a nightmare.

 

Up until now, we haven’t written own layers in dl4j. That work is commencing now and in a short time I will be able to evaluate this aspect more objectively.

Outlook

Currently I see a lot of discussion, experiments and effort being invested into networks to analyze image information. I believe that there is huge potential in the manufacturing industry, and until now I have heard very little about efforts to build solutions for manufacturing.

 

I think manufacturers or producers of manufacturing equipment will require networks of choreographed and aligned networks. Often subsystems or aggregates have to work in a intelligent and semi-autonomous mode while contributing to the coordination or analysis of the whole manufacturing process.

 

So ability to train networks for specific tasks and then join them in larger networks will be important. Also the ability to train a network and then replicate it with slight modifications (such as those required because the next production line has a slightly different configuration) will be extremely important to build products using deep learning efficiently. Last but not least, even with state-of-the-art technology, the hyperparameter tuning of a neural network is a painstaking and elaborate process which, to my opinion, could be one of the main hindrances in bringing deep learning applications to market in a timely manner.

 

In respect to dl4j I strongly feel that that this framework will overtake the current top dogs of deep learning simply by providing the industry tools to build actual products/applications using deep learning. This feeling is motivated by the current condition and the focus of the framework developers. For instance:

  • Dl4j team is working on the solution for hyper-parameter tuning, called Arbiter[8];
  • the community is very active, just check-out the liveliness of the dl4j gitter channel[6];
  • github statistics[9] look very healthy to me and last but not least;
  • from the involvement of Skymind employees both in support of community and evolving dl4j code-base, it seems that dl4j is very central for the business model of this company. And, according to my experience, when commercial enterprize is backing open source project, it gives a huge boost to that project.

 

The work on the described project will continue throughout 2017 and, likely, 2018. Our current plan is to stick with dl4j and use it in production. I would love to hear about your experience with deep learning and currently available deep learning frameworks, so comment on!

 

by Reinis Vicups
reinis(at)orbit-x(dot)de

 

I am freelance software developer specializing on machine learning. I am not affiliated with deeplearning4j or skymind.

The described project is being developed for Samhammer AG[10] and continues as of 2017.

Special thanks to Wolfgang Buchner[5] and other guys for your excellent criticism and corrections.


Angry rantings

 

Curse of Technology on achieving Mastery

When I was younger I sought for mastery in every technology I used. If I recall correctly, I have achieved mastery in Borland Delphi Pascal, shortly after it died[11] (at least in the part of the world visible to me). I attempted to gain mastery on several other technologies every since and concluded this: If I work for a commercial software development company that is successful, there will be a ongoing change of employed technologies because of the reasons of

  • constantly evolving software development technologies,
  • constantly changing market demands leading to employment of different technologies,
  • constantly evolving business model of the software company itself again, leading to changes in employed technology.

So basically, unless your business is to develop frameworks, it is next to impossible to achieve mastery in most of technologies. With 41 I have used more than thousand frameworks and several dozen development languages for at least one project (~6 month to ~3 years). Except couple of languages I haven’t kept much, I sometimes don’t even recall the names anymore.

tl;dr

Working for commercial Enterprizes makes it very hard to achieve mastery in used technologies due to fast evolution of technologies themselves, evolving markets and business models of the Enterprises themselves.


[1]https://en.wikipedia.org/wiki/Technology
[2]as of January 2017
[3]these are my assumptions
[4]https://deeplearning4j.org
[5]https://github.com/wobu
[6]https://gitter.im/deeplearning4j/deeplearning4j
[7]https://deeplearning4j.org/visualization
[8]https://github.com/deeplearning4j/Arbiter
[9]https://github.com/deeplearning4j/deeplearning4j/graphs/contributors
[10]https://www.samhammer.de
[11]http://softwareengineering.stackexchange.com/questions/83009/what-happened-to-borland-delphi

Flowchart vs flowchart

Just recentlly I was about to hold release planning workshop with domain experts of the customer. And to my huge surprize this customer were prepared! They made diagram that displayed current process. And I must admit I liked it.

I am using word “flowchart” to denote way my customer prepared their diagram because it displayed mixed flow of control and objects plus some additional support information. Sure there is similar diagram in UML – activity diagram. I find though activity diagrams quite difficult to explain for someone who is not familiar with UML. Yes, you can teach your customer UML, but what if he is not interested or willing to. What if there is actually alternative and more or less equal ways to display same information without having to learn UML.

Check out the flowchart of my customer (I beautified and modified it ofcourse):

flowchart-vs-flowchart-1

Well, original diagram was even simpler since it didn’t had object flow. I added object flow to the diagram by reflex and now am too lazy to delete it. I think you will still get the point. And the point is – besides simplified display of activities, there are two additional areas on the both sides of diagram that let you

1. much better understand who is having the ball at the moment

2. adds relevant information without cluttering diagram

Yes, it is possible to display same information using activity diagram, e.g. like this:

flowchart-vs-flowchart-2

My opinnion is – the UML-compliant version of diagram is cluttered, responsibilities not as clear as in first version, if activity is shared by two actors (like “agree on delivery conditions based on availability”) – for me a question pops up if placing activity on the border between two swimlanes is formatting error or intended. Additionally, I think that additional information in notes is not as prominent as it is in the first, non-compliant diagram. Finally, I should’ve ben adding third swimlane for final node since it is being executed by someone else and not purchasing agent.

Summary

Sure the differences between two diagrams above are not that huge. But I think that when it comes to acceptance of one or another modeling methodology the devil is in the detail. So I say, for the sake of your customer and productive joint effort, feel free to give up formalism and concentrate on enhancing understanding and readability versus trying to hold on to standard.

Knowledge in software development

Part of this interview “Ivar Jacobson on UML, MDA, and the future of methodologies” where Mr Jacobson comments on main differences between software development methods based on explicit knowledge and those based on tacit knowledge lead me to thoughts I am willing to express in this post on knowledge within software development (methodology).

I am not going to elaborate on definitions here since there’s an excellent article “Convert tacit knowledge into explicit knowledge to ensure better application development” describing differences and co-relations between tacit and explicit knowledge. Please check both, interview and article before reading this since you will need some preliminary understanding about subject.

So, considering above thoughts of the Mr Jacobson and considering argument of Mr Kuhn on conversion process I must say that statement of Mr Jacobson on shortcomings of methodologies based on tacit knowledge was incomplete.

To quote Mr Jacobson on problems with methods based on tacit knowledge – “how do you teach that?” “how do you know what it is?” “(in a team with tacit knowledge) how do you get them to agree on what to do?” “how can you possibly grow that knowledge?”

Well, I have actually answers to those hypothetical questions:

“How do you teach that?” – well you don’t that’s the whole point you show and then show again until other people get the point
“how do you know what it is?” – again, you don’t but that’s OK since you don’t have to articulate it, just show
“(in a team with tacit knowledge) how do you get them to agree on what to do?” – to have a consensus all members must have either same (tacit) knowledge or there should be dominant expert who forces his tacit knowledge upon rest of the team. If this is not the case, getting agreement on what to do will turn out to be lengthy and unlikely productive process, but – result would be an answer to the next question.
“how can you possibly grow that knowledge?” – i say, same way you’d grow explicit knowledge – in a evolutionary way! How do you grow explicit knowledge in first place? To grow any method one will have to add new stuff and because its new there is no information about it within existing method.

To rephrase Mr Kuhn – invention itself is conversion or articulation of tacit knowledge through which it is converted into explicit knowledge. In other words to create explicit knowledge you NEED tacit knowledge in first place.

The conversion process described by Kuhn is looped tho, that is – as soon as you create explicit knowledge, you need tacit knowledge to evolve or re-define that explicit knowledge. New and better definition of explicit knowledge emerges after so called “revolutionary paradigm shift”. Users of this new knowledge start to gain new tacit knowledge immediately in the process of working with explicit knowledge and eventually put explicit knowledge under question thus sooner or later forcing next “revolutionary paradigm shift” and so on, and so forth.

I may be too bold stating that establishment of this cycle actually gave human kind that edge against other animal species by allowing to overcome shortcomings of evolving only with tacit knowledge (because its too slow). Evolution only with explicit knowledge would be even impossible (since It’s tangible. There’s no need to gain experience. It’s something that has been converted to a rule).

Ergo

Well, my conclusions are:

– tacit knowledge actually does the job of evolving things based on that knowledge
– explicit knowledge does the job of formalizing, explaining (learning) and distributing tacit knowledge

Today, only together they give evolution the speed we are used to, the speed we are not willing to give up. Projecting this on software development methodology is straight forward – only method that uses both types of knowledge has a chance of fast evolution.

Since, as far as I know, there is no method yet that would explicitly base itself on both knowledge types I am happy to say that we still got a lot of work to do and a lot of new things to invent 😀

Bring Emma to kindergarten: Requirements outline (2)

This Entry is dedicated to my project Use Case “Bring Emma to kindergarten”, Please read the project page first to get the general idea.

Here it is, formalized requirements outline from the previous post.

Requirements Outline

Chapter 1. Purpose and Scope
1a. What is the overall scope and goal? – Main goal is to bring Emma every working day between 08:00 and 08:30 to Kindergarten
1b. Stakeholders (Who cares?) – Chris, Reinis
1c. What is in scope, what is out of scope? – Starts with getting up and ends with leaving Kindergarten

Chapter 2. Terms Used / Glosary
Lunch – bread & fruits. Joghurt, pudding
Registration time – 08:00 – 08:30
Working day – Mo till Fr with the exception of school break, closing(?) days and comon holidays
KiGa – Kindergarten
Kindergarten – “zum St. Martin”, …. 92712 Pirk
Emma – child (daughter)
Lunchbox – pink, branded “Scouty” has picture of pony and sheep

Chapter 3. The Use Cases
3a. The primary actors and their general goals – Parents to bring Emma early and without the delay to Kindergarten; Child to meet her friends, play, masquerade; Kindergarten personell – to register child upon arrival
3b. The business use cases (operations concept) – Bring Emma to kindergarten
3c. The system use cases – Bring child to kindergarten

Chapter 4. The Technology Used
Household, municipal infrastructure

4a. What technology requirements are there for this system? – municiapal infrastructure should be maintained; household should have power, water, clothing
4b. What systems will this system interface with, with what reqruiements? – phone, baker, butcher

5. Other Requirements
5a. Development process – not applicable
5b. Business rules
Time – 08:00 – 08:30
Child is dressed
Child is not crying in process
Child has lunchbox
Acceptance of the child towards other actors
5c. Performance – use case should be completed in approx. 1 hour
5d. Operations, security, documentation – security on stairs, street, depending on weather conditions (e.g. umbrela oder gloves), health; respective clothing for operations
5e. Use and usability – possibility to parallelize some steps should be investigated
5f. Maintenance and portability – Emma should be periodically washed and fed. Dress and lunchbox should be maintained. Is this Use Case applicable for any child?
5g. Unesolved or deferred – none

Chapter 6. Human Backup, Legal, Political, Organizational Issues
Q1. What is the human backup to system opertaion? – Reinis back ups Chris; Christa back ups Reinis & Chris; Mrs Schwab backs up Christa, Reinis & Chris
Q2. What legal and what political requirements are there? – Reinis wants to participate only if he is not tired or dozy
Q3. What are the human consequences of completing this system? – not applicable
Q4. What are the training requirements? – traffic rules, dressing up Emma, lunch, brush teeth, timing!
Q5. What assumptions, dependencies are there on the human environment? – health, acceptance of Emma

End! Now, let us see what exactly is the purpose (besides obvious one of capturing requirements) of this artifact and what value does it add to our project.

Requirements Outline, what gives?

I already explained in my previous post that I was looking for a way to somehow capture all those social or, in general, human aspects I am unable to capture directlly in use case due to its behavioral nature. So does Requirements Outline serve this purpose?

Short answer – yes, but it needs to be adapted.

Long answer – we have special case of having just one use case defining scope of our project. This demands certain adaption for the requirements outline. Also the fact that the System is not computer based but rather social makes some of the chapters not really usefull or even meaningful. Let us check out some detail:

For starters, 1b. – why isn’t Emma stakeholder? Our motivation was that she does not always care. Sometimes she is willing to go to kindergarten, sometimes she really don’t care and sometimes she wants to stay in bed and is not willing to go to kingergarten no matter argumentation. The discussion on what place does Emma take in this use case we will continue again at some point. Is our assumption that Emma is no stakeholder correct? Is Emma an actor then or, maybe, she is even a domain object? I am not naging on definitions here, but rather trying to bring in clarity since without clear definition we will be probably unable to state clear requirements.

then there’s 1c. – we had a somewhat lengthy discussion about if preparations on the previous evening are within scope. Pro arguments were “well but we need to prepare that food for breakfast” or “if am not going to set alarm clock, we might oversleep…”. Contra arguments were “well but you have to buy food before you can prepare it – should buying be within the scope aswell?” or “you set alarm clock not only to get up on time to bring emma to kindergarten but also to get to work on time”. As you can see defining scope is not trivial at all, especially in cases where parts of process are taken for self-evident. I mean everyone knows that to get up early you have to set up alarm clock and how to do it or, that you have to brush your teeth or eat breakfast in the morning or dont you? I think there is no best practice that guarantees right result. Why did we left preparations on previous evening out of scope? Cause my gut feeling said so!

3a. – check out we defined an Actor for Emma (child). Is this descission right? I mean, aren’t we just driven by our social standarts that prohibit us from treating a person as (domain) object? Wouldn’t it be more appropriate to define her as a part of the system, to neglect her free will and to leave within scope only her attributes and part of behavior relevant to fullfilling given use case?

3b., 3c. – well, duh! Is it really worth writing system use case just to display that we could theoretically generalize Emma to child?…

Chapter 4 – I was about to say “duh!” as we started to write down Chapter 4, but then I realized that this chapter must be adapted before we actually can write something about “technology”. What technology are we actually using in this use case? Alarm clock, kitchen gear, phone, shower head (thats right!), shoe cabinet (technologically very advanced thing) – all very important to optimally complete use case but too general to specifically elaborate on any particular one. Those are all elements of infrastructure! Thus I come to conlusion that Chapter 4 should actually be called “The Technology and Infrastructure used” and should include also descriptions of what infrastrcutre elements are used to accomplish given use case. There is Topic 5d. “Operations, security and documentation” that kinda offers place for mentioning infrastructure still I belive that infrastructure is one of those fundamental aspects of use case and since technology chosen is very often co-related with infrastructure available those two belong together.

4b. – just one remark. See, we mention baker and butcher. It was very nice to instantlly see an added value of actually considering different aspects of requirements. We startet to discuss that we would have to interact mit Phone in those cases when Emma can not attend kindergarten. One of us suddenlly asked, but what about Mrs Häring our baker – we would have to interact with her aswell in case we would forget to prepare lunch for Emma or if our fridge would be empty. In the context – visiting Mrs Häring takes 5-15 minutes thus having serious impact on reaching performance goals of use case and thus should be part of the requirements!

5b. – “Child is not crying in process” say what?!?!? Those of you who were already confronted with bringing their children to kindergarten know what I am talking about. In first couple of weeks or every time after lengthy vacation (or visit at grandmas’) was crying and not calming down for hours on in. Kindergarten personell even called us (using phone system :)) and asked to fetch Emma early since she wouldn’t calm down. This resulted in us having phones placed close and mobiles switched on every time we leave house during kindergarten hours.

5d. – another reason to bring infrastructure to Chapter 4 is operations. We are using municipal infrastructure (pavement) which based on weather conditions or maintenance is not always really operational 🙂

5e. – I think we were unsure if we understood this topic correctlly. Any example or advice would be really appreciated. The only sentence we came up with you can see for yourself.

Chapter 6 Q2. – fact is that I am an “owl” and I must force myself to get up early. This is good to know since everytime Chris can not bring Emma to kindergarten she informs me in advance so that I can get to bed early and lessen “the pain”.

Summary

Finally, a decent best practice to structure all of the requirements. Did we really covered all of them? Again – time will tell as we advance with our project. Just reviewing initial conlusions I was able to draw from requirements outline I see solid base for further elaboration.

Bring Emma to kindergarten: Requirements outline

This Entry is dedicated to my project Use Case “Bring Emma to kindergarten”, Please read the project page first to get the general idea.

Although we discuss only one use case, Terms & Conditions still apply. And, since we have a social kind of use case where all the “human stuff” is very important because the SuD itself runs on humans, their behaviors and issues. I was looking for a Template to structure requirements in a way that would allow to consider this human part of our use case.

Well, I took that easy path and adapted… Requirement Outline proposed by Alistair Cockburn who adapted it from the template that Suzanne Robertson and the Atlantic Systems Guild published on their Web site and in the book Managing Requirements (Robertson and Robertson, 1999).

Unfortunately, I haven’t thought of putting behind Topic numbers their names in the paper version of the Requirements Outline as we wrote it, since the template was in front of us and I kinda didn’t realize I have to show it people that might actually have no access to it. That’s why (and also because I wanted to have an English translation) I will write it (outline) down one more time and attach original version for those who love my handwriting.

Since this posting has already reached a critical mass, I will move English version of outline along with my analysis to the follow-up.

Bring Emma to kindergarten: usage narrative (2)

This Entry is dedicated to my project Use Case “Bring Emma to kindergarten”, Please read the project page first to get the general idea.

Well, besides ugly handwriting what else can we say about two usage narratives from the previous log? Let us put side by side all the artifacts described in two narratives like this:

Artifacts from narrative I call “First version” Artifacts from narrative I call “Second version”
1. Every working day
2. Reinis
3. more often Chris
4. around 8:30
5. Emma
6. bring to Kindergarten
7. washed
8. dressed up
9. fed breakfast
10. 5 minute walk
11. crossing no streets
1. prepare breakfast on previous evening
2. prepare dress
3. set alarm before sleep
4. get up when alarm goes off
5. prepare flakes
6. Emma
7. wake Emma if she’s still sleeping
8. Emma eats breakfast
9. Emma goes bathroom
10. we dress us up
11. we make hair
12. brush teeth
13. pack meal
14. dress up
15. not later than 8:20 leave house
16. Kindergarten registration till 8:30
17. Don’t forget Lunchbox!

Table 1: Artifacts from both narratives

Things I expected:

– Overall granularity will differ. This is visible by simply counting number of artifacts;

– Overall focus will differ. Every actor/stakeholder participating in use case has different goals thus focusing on slightly things

– Scope will differ. Guess this is the main reason requirements management is such a tedious job sometimes

Things I didn’t expect:

– Overall granularity differs only little. Second narrative has 6 additional artifacts but if we look more closely at the content – artifacts 1, 3 are not even covered in first narrative and artifacts 2, 5, 7, 11, 12, 13, 14, 15 and 17 just add to granularity. In following table I have tried to group artifacts based on type and what I got looks to me a good base for a use case outline. We’ve got actors, trigger, pre and post conditions along main success scenario.

– Scope differs only little. I took liberty to define what artifacts describe pre and post conditions of the use case before we made an In/Out List just to illustrate how both narratives differ in definition of scope. As you might see, second narrative defines preparations on the previous evening (dress, breakfast, alarm clock) as part of use case. Final definition of scope will be defined by in/out list as soon as we make it 🙂

– In both narratives focus is on phase between getting up and getting out of the house. What I mean is this – process of bringing Emma to kindergarten is vaguely mentioned only in first narrative (artifacts 10 and 11), is not mentioned in second narrative at all, but period between getting up and getting out of the house is covered by 3 artifacts in first narrative and by 9 artifacts respectively in second one (10 if you count validation artifact 17). This is kind of weird since getting to kindergarten and actually delivering Emma in kindergarten are rich of content (e.G. one have to find Emma’s locker, undress Emma, bring her to the right room and formally inform kindergarten personnel about Emma’s arrival, same is true for moving from house to kindergarten).

“First version” “Second version” Artifact type
[not covered] 1. prepare breakfast on previous evening
3. set alarm before sleep
Pre conditions
1. Every working day 4. get up when alarm goes off Trigger
4. around 8:30 15. not later than 8:20 leave house
16. Kindergarten registration till 8:30
17. Don’t forget Lunchbox!
Guarantees
2. Reinis
3. more often Chris
5. Emma
6. Emma Actors
6. bring to Kindergarten 7. wake Emma if she’s still sleeping
13. pack meal
Scenario
7. washed 9. Emma goes bathroom
11. we make hair
12. brush teeth
Scenario
8. dressed up 2. prepare dress
10. we dress us up
14. dress up
Scenario
9. fed breakfast 5. prepare flakes
8. Emma eats breakfast
Scenario
10. 5 minute walk
11. crossing no streets
[not covered] Scenario

Table 2: Aggregated narratives

Summary

I say, narratives deliver us up front certain amount of analytical data. Participation of multiple narrators probably help even further since there’s material to compare and differences are likely to hint out stuff that should be particularly elaborated upon (such as what sub processes narrators concentrate on, how they define scope etc.) I am practically able to build Use Case outline with only those two short narratives.

The true added value of narratives we will see in upcoming phases where I get my hands dirty and churn out the detail. At the moment I am keen to see how much of the structure I extracted out of narratives will remain at the end of this project.

Bring Emma to kindergarten: usage narrative

This Entry is dedicated to my project Use Case “Bring Emma to kindergarten”, Please read the project page first to get the general idea.

Alistair Cockburn suggests

In this narrative, invent a fictional but specific actor and briefly capture the mental state of that person – why he wants what he wants or what conditions drive him to act as he does.

I want to test if its true that narrative eases one into the use case itself and, also, want to check out what sort of differences there will be in narratives of my wife and me. This is what we’ve got:

First version:

Second version:

I will give my analysis on the content in an follow-up until then – presenting the raw result…