 |
| Social Modeling for Requirements Engineering |
I have been reading Verna Allee‘s work on Value Network Analysis and recently, upon Graham Hill‘s suggestions, the i-star framework. I have even ordered the book “Social Modeling for Requirements Engineering” to learn how to apply the i* to requirements gathering. I am really looking forward to that book, but it wont be in my hands since it has to be imported from the US. But that’s fine since it will allow me time to digest what I have read about it so far and think about it in context of some of the systems at various stages of development that I am aware of.
Now I am sure you are familiar with this scenario, especially if you work at a large organization, when you want to book rooms for meetings and the booking system says that its already booked by someone else? But then in reality its not being used? Well, to solve this issue, the current line of thought is a new meeting concierge application was to be to figure out who has been missing out on using their booked rooms for 2-3 times in a row and then ‘reprimand’ them with a message or some other manner. When the people designing the system told me about how they were trying to figure out how to ascertain if someone was indeed using the systems, something struck my mind.
How do the people who are stuck with the current systems work around the system? If we know the person who has blocked the room, we go over to the other person’s desk and check with them and negotiate if we can get the room. Or we directly go and have a peep into the room to see if its indeed being used. Or we check with reception or who ever handles the room bookings. Then this idea came to me as a brainwave, out of nowhere since I had never thought about this problem before. What if we can allow the user to be able to communicate from within the system with the person who has pre-booked the room? What if there were an integration with OCS (or whatever IM is deployed) that allowed the user to chat with this other person? Or how about there is a ‘button’ there that lets the user to ask the other person if he would like to reassign the booking to him? They system could send an email to the other person and he could reply with a simple yes or no and the system would act accordingly?
Where the current approach is one of process & compliance, the later is one of enabling communication, especially with others in the organization whom you might not know because its a huge company? Well, we ourselves at Cognizant do have more than 100,000 employees worldwide and most of our buildings house thousands of employees. So it is not a remote possibility that the two users would not know each other.
So what was different in my approach to the problem? In real life the Actors of the system do not use the system to get this done. They interact with each other to negotiate. In traditional requirements gathering, we only try to figure out what the system should do, not what the actors do to get the job done. We cannot capture that as use cases or in UML. However, in an i* framework we really do try to figure out how the Actors interact with each other, what are their motivations, etc. Could i* framework have come up with what I got as a brainwave? I still do not understand i* properly, so hope to revisit the above scenario later and answer you.
