Is Your Software Usable?

Introduction

In practice, the usability or user-centered design (UCD) technologies are underused in software engineering. This is because usability or UCD is not only related to computer science, but also involved by psychology and other subjects. What’s more,  usability technologies are developed separately outside the software engineering world.  They have their own theories, concepts, models, and tools. Therefore, usability technologies may be difficult for software developers to understand and implement.

This article is about to introduce the basic concepts of software usability and explain why it is important to software development. Then, we will explore a potential solution to integrate usability engineering into software development and the methods of usability evaluation.

What is software usability?

It is a preconception, “Usability only refers to the appearance of the software product.”

Usability or UCD is a term related to the concepts of multiple areas, like computer science, psychology, human factors and so on. Briefly, I think usability is a user-centered measurement based on the subjective perspectives and experience of users. The aim of usability is to reflect the quality of the interactions between software products and users.

One of the most popular explanation of usability is based on five dimensions [1][2]: learnability, efficiency, memorability, error rate, satisfaction. More specifically, learnability measures the time required to make a new user become skilled in using a particular software product. Efficiency means how convenient the software is to help a user improve his productivity. Memorability refer to how quickly a user can pick up his knowledge about the software product after a period without using it. And the error rate here means how many errors a use may make when performing his tasks. Finally, satisfaction represents how willing a user may be to use the software product.

In my opinion, measuring software usability based on these five attributes may be inappropriate. Because some criteria are overlapped with others. For example, memorability is highly related to learnability. If a software product is easy to be understood and learned, it may probably be efficiently memorized and be quickly picked up after a period of no using. Efficiency should take error rate into consideration, because high error rate can reduce the performance of efficiency significantly. Moreover, satisfaction is actually influenced by all the other criteria. It should be regarded as the essence of the usability, since usability is a user-centered measurement. In my view, it is arguable that  there may be only two key attributes of software usability, understandability and efficiency. Understandability means software product can be understood and learned quickly by user without too much information needed to remember. Efficiency means required tasks can be performed by simple and a few operations which can also reduce the errors made by users and increase users’ productivity.

Why it is important?

In my view, the center of the software industry is user. High usability can lead to the high popularity of the software product. However, low usability can reduce the original values of the product and users may prefer using other alternative software products with good user interface. Let’s make up a simple but inappropriate example, we designed a more powerful tablet OS than Andriod or iOS, but users have to type command to perform all the tasks. That can be a huge disaster to users.

Usability engineering is not just a decorative process after the whole software product is already built. It should take part in the software development life cycle early. Because some end-users’ interests or preferred behaviors may influence the functions of the software, even the architecture of the system. For example, for a particular software, users may prefer being able to cancel any ongoing tasks under any conditions and backup to the previous state. This kind of need may affect the system design.

Integrating usability engineering in software development

The good point for usability engineering to engage in software development life cycle may be the use case analysis phase which is widely used in modern iterative software development [3]. In each iteration, a usability team will focus on task analysis. task analysis is about to explore the expectations of end-users, how users perform their tasks, what is the responsibilities of users and understand the motivation and strategy behind users’ behaviors. The main methods of task analysis are site visit, interview and survey. Once usability analysis and use case analysis have been done, the usability team and the software development team should negotiate with each other to investigate the factors that may influence the future design of each team. Communication is extremely important between two teams. Since these two teams are speaking different languages and using different tools, it is necessary to have at least one ‘bilingual’ in each team who has basic knowledge about the technologies used by other team to make the communication more effective and efficient. After discussion, the usability team will  focus on interface design and prototyping. And then test and evaluate the usability of the prototype for the next iteration.

Usability evaluation

There are a great deal of methods that can be implemented in the evaluation of usability, like usability testing, thinking around, and heuristic evaluation. Among these technologies, heuristic evaluation is the most popular one. This method performs usability tests with a group of usability experts. They test the prototype based on a set of principles to discover and identify usability problems. Due to its cheap and efficient nature, heuristic evaluation is a very good fit in iterative software development. However, usability is a kind of subjective measurement, views from a small group of experts may bias the results, especially when it comes to the public. So, I think, besides heuristic evaluation, we can implement thinking aloud approach at the same time in the early development life cycle. The less complete our product is, the more problems can be directly exposed by users. These negative attitudes can provide experts more psychological information for future heuristic evaluation.

Conclusion

In this article, we introduced the concept of software usability that usability not only refer to the appearance of the user interface but also relates to other areas like psychology and human factors. It is also essential to recognize the importance of user-centered design. We also explored the possible approach to integrate usability engineering into software development and the methods of usability evaluation. I think software development can benefit a lot from the integration of usability engineering. Because user is the center of the software industry, a powerful software need an efficient and easy understandable interface to support and attract end-users to perform their tasks.

References

[1] Holzinger, A. (2005). Usability engineering methods for software developers. Communications of the ACM48(1), 71-74.

[2] Ferré, X., Juristo, N., Windl, H., & Constantine, L. (2001). Usability basics for software developers. IEEE software18(1), 22-29.

[3] Seffah, A., & Metzker, E. (2004). The obstacles and myths of usability and software engineering. Communications of the ACM47(12), 71-76.

Response Article to “Some new ideas for successful software management” by s1323594

INTRODUCTION

This is a response article to “Some new ideas for successful software management” [1].

In the original post, the author introduced an interesting idea of comparing software development to movie production and explored the similarity of these two industries on  economic performance. Also, the author stated four patterns of steering leadership style project management in iterative software development and claimed his/her own views about this strategy.

In this article, I am going to emphasis my agreement and disagreement with some concepts and ideas of the original post. I will argue that  software production and film making are not quite alike, and the concept of requirement is really important in software development, therefore, it should not be replaced by specification. And I also think steering leadership strategy can be very useful in practice, because of its idea of steering and balance management.

DISCUSSION

Is software project development like movie production?

I partly agree with this interesting idea. Actually, this idea inspired me to explore the similarities and differences between software industry and movie industry. The author claimed that the economic performance of software industry is quite similar to that of movie industry. This is true, because both software industry and movie industry are highly business-related activities. Business-related activities are generally motivated by profits. Therefore, popularity, user reviews, and sales are important metrics for the success of both software projects and films. Another similar feature I think is reuse. More specifically, in modern software projects, reusing systems or components which have already been developed is very popular since this strategy helps save time and money. Likewise, in film making, all the actions in a particular location will be collected and recorded as raw materials at the same time. I think people will never want to come back again to record following stories after traveling hundreds of miles. This is the location reuse in film production. However, there is an essential difference between software management and movie making. In my opinion, the life cycle of movie production is much closer to the waterfall model, because film making contains several sequential stages such as changing stories to screenplay, doing preparations for film shoot, recording raw materials, editing the film and so on [2]. On the other hand, iterative models are usually exploited in modern software project development, since requirements, technologies, business environment as well as other factors keep changing. As a result, I believe that the idea of regarding software development as movie production is inappropriate.

Requirement or Specification?

I disagree with the point that the word “requirement” is misused in software development.  The argument of the author is that components of a software project are always changing. It seems a little bit vague. So I read the original paper [3] instead and found that the explanation of Walker Royce was that “requirement” is literally nonnegotiable, however, in practice, requirements are always negotiated and changed. Therefore, he suggested to use the word “specification” instead. But from my point of view, using “requirement” to describe user need is proper. I think requirement is used to identify the baseline of user need and specify the topic of the project. It should provide an abstract description of the final goal which is usually regarded as unchanged during the project, because it captures basic user needs and any basic need changes significantly affect the project. However, specifications are actually the details or extensions of these basic needs which help improve the understanding of user needs.  In the early stages of software development, the requirement is simple and vague, then it evolves gradually as the software development iterates. For example, a use asks developers to build a house for him. Then “a house” is identified as the requirement, therefore, the project begins. A few days later, user says I’d like to have two meeting rooms. Then, the requirement is still “a house”, but extended by the specification “two meeting rooms”. This kind of process will continues until the house becomes detailed enough. The basic need “a house” remains unchanged. Because it is what the project starts with. If, one day, the user says I don’t want that house, I need a plane, then the entire project should be thrown away. Thereby, I don’t think the word “requirement” is misused in software development and requirement should be stable to some extent. The concepts of requirement and specification are both very important. They are used to identify the basic user need which should not have significant changes and details or extensions of user needs which can be modified, respectively.

Steering leadership style

The original post introduced four patterns of steering leadership style. I think they are really inspiring and may be useful in setting up intermediate checking points for evaluating current progress of the project and making plans of improving the system achieved.

Scope Management

The original post mentioned the idea of replacing the concept of requirement with specification in this part again. However, I totally disagree with this point and reason is as above. But I do agree with idea of scope management. In my view, the main purpose of scope management is to provide stakeholders a clearly in-depth look on the contract between developer and users, and manages a plan or interim steering targets based on current understanding and knowledge for future works. This idea is very important in iterative software development, because we should make sure to have an agreement with stakeholders on their requirement in current phase and have a clear plan and objective for the next iteration.

Process Rigor

The author stated that different phases of software life cycle should have various emphasis. I totally agree with this idea. To my understanding, process rigor is about the trade-off between creativity and rules based on the context during software development. In the early stages, the cost of changes is relatively low, we should make less constrains and encourage developers to think creatively so that better designs may be discovered during early phases. However, in the late stages, the cost of changes can be extremely high. Therefore, we should focus on making the product complete and robust instead.

Progress Honesty

The original post emphasized the importance of trust between stakeholders and developers. It seems not very clear about this pattern. I think the key point is that there may be lots of mistakes, problems, and immature designs during the early phases, however, stakeholders should be confident in the ability of the development team without too much interference. Because these mistakes are expected to happen so that the drawbacks of the production can be discovered early. Also, effective communication is required between developers and stakeholders, therefore, problems can be negotiated and solved immediately to make sure the increments of the product after each iteration. Efforts should be put into making progress rather than enforcing standards in the early phases.

Quality Control

The author exhibited that, in quality control, testers and testing should be the most important element in software development. I think this may be not accurate enough. To my understanding, the main point of quality control is the importance of integration testing in early life cycle and the argument in the original post is one of the observations of implementing this strategy. We can be aware of the architectural limitations and weakness in early stages using integration-first testing. Interfaces, system-level behaviors and completeness can be tested so that we can assess the progress and quality of the project more accurately. This can be very useful for future work management and tests.

CONCLUSION

The idea of regarding software development as film making is not quite appropriate. Also, I think requirement is an abstract description of basic user needs. It is the foothold of a software project and will be detailed and extended by various specifications as the project evolves. In addition, I think the success of steering leadership strategy is steering and balance. In iterative software development, steering means using current knowledge to find out proper target for the next iteration to avoid risks and make increments of the product. Balance means a project manager should not be a follower of any single development model, but effectively exploit the strengths of different models, technologies, and thoughts in an appropriate way based on the practical context. It is impossible to manage all software projects using a single models, therefore, balance among various technologies may be a potential solution to modern software development.

REFERENCES

[1] s1323594. (2014). Some new ideas for successful software management. http://blog.inf.ed.ac.uk/sapm/2014/02/13/some-new-ideas-for-successful-software-management/

[2] filmmaking. http://en.wikipedia.org/wiki/Filmmaking

[3] Royce, W. (2005). Successful software management style: Steering and balance. IEEE software22(5), 40-47.

New Role of Requirements Engineering in Software Development

Introduction

Since there are increasing needs of rapid software delivery, low development cost, and quick responsiveness to requirement changes for software development in many areas, especially in the business world, the traditional discipline of ‘requirement first’ is not valid for many types of software projects any more. Therefore, it forces us to discover new approaches to implement requirements engineering (RE) process in software engineering.

Background

Requirements are expectations of the stakeholders or customers which specify how the software should behave. They describe the properties and feature of the required software system. Therefore, requirements provide both guidelines and constraints for software development. Requirements engineering process is a set of activities which aim to understand and identify the desires of the customers, deal with requirement conflicts and changes, and refine stakeholders’ expectations into specifications which can be feasibly implemented by software developers.

According to the paper [1], no matter what the detailed RE process is, there are some vital components in RE process.

  • Elicitation: Identify and gather sources of information about the software system.
  • Analysis: Understand the requirements of the customers including overlaps and conflicts.
  • Validation: Check whether the requirements are what stakeholders expect.
  • Negotiation: Reconcile requirement conflicts in order to reach the consistency.
  • Documentation: Document all the requirements in formal documents.
  • Management: If requirement changes occur, they should be managed carefully.

1

Fig. 1 The activity cycle of the requirements engineering process [1]

The relationships among these basic elements are shown in Fig. 1. In practice, the RE process iterates continuously during the software development.

New Challenges for RE

In the last century, the waterfall model has presented a great impact on software engineering. It emphasises that the system requirements should be complete and consistent before the software development process begins. Once the system requirements have been defined, no significant change is expected to occur during the software development since that may lead to restart or doom the project. In practice, it is obvious that the initial assumptions of defining complete and consistent requirements before the software development process are unfeasible, especially, for those large scale projects. Moreover, requirement changes are inevitable, since customers may obtain new visions about the problems which lead to requirement changes. Furthermore, there are also some other factors such as the business environment and policy changes which may also give rise to changes in the software requirements.

Due to those essential drawbacks, traditional discipline is no longer useful for a majority of the projects today. There are four main challenges which lead to rethinking the role of RE process in software development [1].

  • New software development approaches such as construction by configuration arise. The dominant method used in software development is reuse now, especially in the business world. Briefly, construction by configuration means assemble and integrate existing systems and components to create new systems. Therefore, the software requirements depend on not only the expectations of the customers but also the capabilities of existing systems and components.
  • Application quickly delivery. Business environment is changing incredibly rapidly. As a result, new software applications are required to be designed, implemented, and delivered as soon as possible.
  • The requirements change increasingly quickly. Due to the changing business environment, it is evitable that that new requirements may be emerged and current requirements may be changed within short intervals.
  • The consideration of return-on-investment (ROI). Based on RIO, reuse may become one of the most efficient approaches applied by most companies.

Integrating RE with system development

In order to deal with the challenges described above, RE process and system implementation should be integrated. As a guideline, Ian Sommerville [1] introduced three important approaches to tackle these problems, among which, I think concurrent RE and RE with commercial off-the-shelf (COTS) acquisition may be solutions with the most potential.

Concurrent RE

In concurrent RE, we use a software outline to start system development process. During the software development, not only RE activities including elicitation, analysis, validation, and negotiation are concurrent, but the RE process and other processes such as system design and implementation are concurrent as well. This concurrent approach is applied in agile methodologies such as extreme programming (XP) where RE and other processes are integrated.

As mentioned in the paper [1], there are three main advantages using concurrent RE.

  • Process overheads may be lower. Less time will be spent on analysis and documentation for requirements, since requirements can be captured more precisely and rapidly.
  • Critical requirements can be identified and implemented in the early stage. Communications between software engineers and stakeholders can be more efficient, because of the concurrency of different RE activities.
  • Respond quickly to requirement changes. Due to the iterative cycles of requirement identification and documentation, we can respond to requirement changes more quickly with relatively lower costs.

However, documentation will become a problem in XP, since XP software development is based on the stories and scenarios on cards. There is no formal documentation and software engineers usually discard them after implementing the system. The possible solution may be that we can extract key words and behaviors or critical services from customers’ descriptions and then document them for future uses in requirement analysis and change management.

RE with COTS acquisition

So far, COTS systems are already available in most areas. If we can successfully develop a new system using COTS systems and configure them to interoperate with each other, it is obvious that this new system will have lower development costs and quick software delivery.

There are two aspects that will influence the RE process with COTS acquisition. One is the selection of COTS system. The other is the interoperability of COTS systems.

In COTS acquisition, it is usually impossible to find one specific COTS system which matches all the requirements. However, if we identify the key requirements carefully, there should be a set of COTS systems that can fully or partly match these critical requirements. After that, we can consider adapting and extending more detailed requirements based on the capabilities of the candidate COTS systems. This process is called procurement-oriented requirements engineering (PORE) [2] and it will continue until the most appropriate COTS system is discovered.

Companies using various software systems are always concerned about the interoperability between new systems and systems that have been already deployed. From a RE perspective, the interoperability can be simply achieved by using open interfaces and standards. However, this kind of requirement is not enough to deal with practical problems [3]. Therefore, Soren Lausen [4] defined a new type of software requirement called open-target requirement, in order to lower the risk of failure in integrating COTS systems.

Conclusion

Traditional RE discipline of ‘requirement first’ is no more valid for many types of software project, especially, for large scale projects. Moreover, new challenges such as rapid software delivery, low development cost, and quick responsiveness to requirement changes in software development in many domains also force us to rethink the role of RE process in software engineering. Therefore, the idea of integrating RE process with system implementation arises. Concurrent RE process, which has been applied in agile methodologies such as XP, is one of the potential solutions providing quick responsiveness to requirement changes. The other one is to tackle with those demanding challenges using RE process with COTS acquisition based on reuse. Due to the changing business environment and rich resources of COTS systems, COTS acquisition is quite attractive to business companies. Although this approach is limited used in business applications, it has the potential to be extended to other domains such as embedded systems. According to the challenges and characteristics of today’s software engineering, it is arguable that integrated RE process will become popular in software development.

References

[1] I. Sommerville, “Integrated requirements engineering: A tutorial,” Software, IEEE, vol. 22, no. 1, pp. 16–23, 2005.

[2] N. A. Maiden and C. Ncube, “Acquiring cots software selection requirements,” Software, IEEE, vol. 15, no. 2, pp. 46–56, 1998.

[3] B. Boehm and C. Abts, “Cots integration: Plug and pray?” Computer, vol. 32, no. 1, pp. 135–138, 1999.

[4] S. Lauesen, “Cots tenders and integration requirements,” Requirements Engineering, vol. 11, no. 2, pp. 111–122, 2006.

[5] W.-T. Tsai, Z. Jin, P. Wang, and B. Wu, “Requirements engineering in service-oriented system engineering,” ICEBE 2007. IEEE International Conference on e-Business Engineering. IEEE, 2007, pp. 661–668.