The IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990) defines software design as "the process of defining the architecture, components, interfaces, and other characteristics of a system or component" and "the result of [that] process". In essence, it's the analyzing of requirements to produce some kind of description of what you intend to build. The end result of the design activities are the equivalent to blueprints for building a building.
Design is usually broken down into a high-level (or top-level) description of the system that identifies various components and how components interact with each other as well as a more detailed description of each of those components that allow them to be constructed.
When you are talking about design at any level, you begin to think of concepts such as distribution (what components will be performing what tasks and where those components will be located), concurrency and task processing, data and events, error handling and fault tolerance, data persistence, interaction and presentation. You also consider the quality attributes (such as maintainability, testability, portability, robustness) of the system and its components.
How you approach design depends on the process methodology that you are using to build the system. For example, in a sequential life cycle, you typically perform "big design up-front" (BDUF), where you take your requirements and produce a high-level design, finalize it (for the most part), use that to create detailed designs, and implement that design. In a more iterative and incremental methodologies, you need to consider all known requirements, but you focus your efforts on designing (and then implementing) a subset of those features at any given time, evolving your product and its design as your add additional features.
The specific approaches and techniques that you use to design your system will also vary depending on what the system is. For example, designing a website for your local little league team, designing a web application for Amazon, and designing software that controls aircraft are all very different in terms of formality and what you need to formally document. The specifics of inputs, activities, and outputs are part of the design activities should be specified in your project planning documentation (which again, might vary in formality from verbal agreements to a large specification, depending on the type of project).